blueprint: the submenu items onclick are not triggered after click the submenu itself
Environment
- Package version(s): 3.6.1
- Browser and OS versions: Chromium 69
Steps to reproduce
submenu > sub item 1
sub item 2
The normal usage is hover on submenu and click sub item 1 to trigger sub item 1 onClick as above.
- when submenu popup is shown as above, click the submenu item itself. the
onClickof submenu itself is triggered - then click the sub item 1 or sub item 2
Actual behavior
sub item 1/sub item 2 onclick is not triggered after click the submenu itself
Expected behavior
sub item 1/sub item 2 onclick still triggered normally after click the submenu itself
might related https://github.com/palantir/blueprint/issues/2796
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Reactions: 1
- Comments: 15 (9 by maintainers)
I’ve dug a little deeper into this, and I think @gasolin is actually onto something bigger. What I’ve found is that when a
PopoverwithinteractionKindHOVERhas its target clicked or otherwise focused, the next mousedown (not click) anywhere on the document causes the popover’s overlay to close itself. (the nested submenu popover in this case, not the outermost one)Setting
autoFocus={false}may appear to fix things on the surface, but all it’s doing is helping to avoid creating the conditions that trigger the bug, but those conditions can still be encountered in different ways, and when they are, the buggy behavior is still exhibited.This behavior is not immediately visible, because 1) in the majority of cases that the target gets focus, it is also being hovered, so the popover’s open condition is still being met, reopening it without delay; and (more interestingly) 2) if a popover’s target is clicked, causing the document’s next mousedown to close it, and that mousedown event happens to be on an element inside the popover’s contents (e.g. a
MenuItem), the popover’s close transition lets the element linger on the screen just long enough for it to catch the mouseup event of a typical click (although not a long slow one) and therefore have its onClick handler called, making it appear that the menu item was clicked normally and that the click was what caused the popover to be dismissed (which, because the outermost/parent popover is not dismissed - it has no reason to be - makes it appear to be an issue withshouldDismissPopover,Classes.POPOVER_DISMISS, etc when really it has nothing to do with those).This bug is actually reproducible in the docs examples, although it’s hard to even notice unless you’re looking for it.
Go to the “Interactions” section of the popover docs: https://blueprintjs.com/docs/#core/components/popover.interactions
Hover the “HOVER” button and wait for the popover menu to pop up
With the cursor still hovering over the HOVER button, click on the button
Move the cursor onto a menu item in the popover
Click the menu item and don’t release the mouse button. You’ll notice the popover will close, even though all the menu items are
shouldDismissPopover={false}You’ll notice that without clicking the target button first, the menu items behave as expected (the popover stays open). Also, if you click quickly enough, you can visually see the menu item’s styling change to its active state indicating that it’s catching the entire click event before the popover is finished closing.
I also think this might be behind #2796 (onClick will fire if the user clicks quickly enough, but if too much time elapses between the mousedown and the mouseup of the click, then the event won’t fire, resulting in behavior that might appear to be nondeterministic)
I’m screwing around with some possible fixes.
I’m experiencing this too, and it makes my app feel really flakey. @giladgray I feel like the “Status: needs more info” is no longer applicable, as you can see this behavior in the docs today: https://blueprintjs.com/docs/#core/components/menu
If you click on “Settings” before you click on “remove application” then “remove application”'s click does not dismiss the menu - this is indication that the actual “remove application” menu item is not firing at all!
and the
autoFocus={false}does NOT fix the original problem reported in this bugAlso seeing this issue as well. Let us know if we can help in any way @adidahiya 👍
@gasolin try adding
autoFocus={false}to your topmostPopover. menu item submenus disable that prop because of this exact issue. further, it makes sense for a dropdown menu to leave focus on the original target rather than pulling it into the menu that was just opened.i’m considering changing the
Popover autoFocusdefault to false, but will not be able to do so until 4.0