Hamburger menu is not modal |
|||
Issue descriptionUserAgent: Mozilla/5.0 (X11; CrOS x86_64 10575.40.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.49 Safari/537.36 Platform: 10575.40.0 (Official Build) beta-channel link Steps to reproduce the problem: 1. Open a new tab. 2. Notice the blinking cursor in the omnibox. 3. Click on the hamburger menu. 4. Notice that the cursor is still blinking in the omnibox. 5. Type the letter "h" What is the expected behavior? The cursor stops blinking in the omnibox when the menu is opened. What went wrong? The hamburger menu does not appear to be be modal. For example, focus is not removed from the omnibox. However, keyboard input *is* directed to the menu. When I type "h", the menu item for "history" becomes highlighted (correct) even though the cursor is blinking in the omnibox (incorrect). This issue also has other negative user effects. For example clicking the "close tab" button while the menu is open closes the tab (and dismisses the menu) instead of simply dismissing the menu. If this behavior is desired, then the "close tab" button should highlight red on hover (as it normally does when clicks will close the tab). Currently, the button flashes red after being clicked. Additionally, the web page under the menu is also interactive while the menu is open, contrary to the behavior of Material Design popup menus on other platforms. Did this work before? N/A Chrome version: 67.0.3396.49 Channel: beta OS Version: 10575.40.0 Flash Version:
,
May 20 2018
Menus are never modal in desktop UI so this part shouldn't change, but the cursor bug and the close button bug should be obviously fixed.
,
May 20 2018
I think there are multiple different issues here. Continuing to flash a cursor in the omnibox or web content seems distinct from things like "clicks outside the menu not only dismiss the menu but are delivered to the clicked on item,yet while the menu is open there's no hover feedback". For the former, I assume the cursor reflects that the element in question does not lose focus, because the menu has not taken keyboard focus. It's not clear to me if it should be considered to have taken keyboard focus. Probably so, but I'd want an accessibility opinion. For the latter, I think we do want clicks outside the menu to take effect, not just dismiss the menu. I assume not getting hover effects is an artifact of menus spinning a nested event loop, and could be very hard to fix. Perhaps sky@ has an opinion here or knows how to move this forward; I don't.
,
May 20 2018
> I assume the cursor reflects that the element in question does not lose focus, because the menu has not taken keyboard focus. If you type "h", the input is directed to the menu (i.e., the "history" entry in the menu becomes highlighted) rather than to the omnibox. Some systems calls this "activation" rather than "focus". I might be misusing terminology. The point is that the cursor is flashing in the omnibox but keyboard goes to the menu, which is a mismatch.
,
May 20 2018
Sorry, I wasn't clear. I understand that keystrokes are acting as accelerators on the menu -- I'm saying that I suspect they're doing that _despite_ the menu not having true keyboard focus (I'm suspecting it's hijacking the event handling process to steal these keystrokes before the focused element gets a chance).
,
May 21 2018
I think we should temporarily move focus when a menu comes up to avoid issues such as the cursor in textfields still flashing. As to not processing pointer-events outside of the menu, 826517 may have fixed this. |
|||
►
Sign in to add a comment |
|||
Comment 1 by abarth@chromium.org
, May 20 2018Components: -UI UI>Browser>Core