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.

  1. when submenu popup is shown as above, click the submenu item itself. the onClick of submenu itself is triggered
  2. 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)

Most upvoted comments

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 Popover with interactionKind HOVER has 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 with shouldDismissPopover, 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.

  1. Go to the “Interactions” section of the popover docs: https://blueprintjs.com/docs/#core/components/popover.interactions

  2. Hover the “HOVER” button and wait for the popover menu to pop up

  3. With the cursor still hovering over the HOVER button, click on the button

  4. Move the cursor onto a menu item in the popover

  5. 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}

  6. 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 image

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 bug

Also seeing this issue as well. Let us know if we can help in any way @adidahiya 👍

@gasolin try adding autoFocus={false} to your topmost Popover. 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 autoFocus default to false, but will not be able to do so until 4.0