Fluentui: ContextualMenu Closes on OSX Modifier Keys

[alxHenry]

Bug Report

• __Package version(s)__: 5.23
• __Browser and OS versions__: Chrome - OSX Sierra

Priorities and help requested (not applicable if asking question):

Are you willing to submit a PR to fix? Yes

Requested priority: Normal - May be an accessibility issue?

Products/sites affected: Yammer

Describe the issue:

When you have the ContextualMenu open on OSX, pressing command or option will close the menu. This can be annoying for a situation where a user wants to command click to open a link in a new window. It also may have accessibility ramifications, but I'm unsure on that.

Expected behavior:

Option or Command would not close the ContextualMenu.

If applicable, please provide a codepen repro:

Go to demo page on OSX, click a ContextualMenu example to open the dropdown, press Option or Command and observe the dropdown close.

[dzearing]

I believe this is because in Chrome, pressing Option pulls focus away from the DOM to the hamburger menu in the browser chrome. The same happens on Windows when pressing Alt.

I agree this is annoying. Trying to gauge the best fix.

We could:

1. Leave open if focus is moved from the DOM to an unknown location.
2. Close menu if focus has been moved to anywhere else within window or documentElement.

@joschect thoughts?

[joschect]

@dzearing The contextualmenu/callout already shouldn't dismiss if the window gets focus. I have no other ideas as to what could cause this. The only keydown that the menu cares about is escape. If the document is what's being focused, then we could add that as an exception.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions to Fabric React!

[andrewbranch]

FWIW, it's not unique to Chrome; it happens in Safari as well (haven't tested others). Also, haven't experienced this to be true myself:

I believe this is because in Chrome, pressing Option pulls focus away from the DOM to the hamburger menu in the browser chrome.

Maybe it's a user setting, but option doesn't blur stuff in the document for me in Chrome or Safari. Also note that the issue isn't just for the option key, it's for command (⌘) as well.

[stale[bot]]

This issue has been automatically marked as stale because it has not activity for 60 days. It will be closed if no further activity occurs within 14 days of this comment. Thank you for your contributions to Fabric React!
Why am I receiving this notification?

[vdepizzol]

The same problem happens when I use the "Zoom" accessibility feature from macOS. I configured my system to use Control + Option as modifier keys, and menus will close as soon as I try to zoom in.

[andrewbranch]

I got so fed up with this in VSTS that I did some digging myself, and discovered that this was done on purpose 😱: https://github.com/OfficeDev/office-ui-fabric-react/pull/3923

It's worth noting that in current master, the behavior has switched from the keyDown handler to the keyUp handler: https://github.com/OfficeDev/office-ui-fabric-react/blob/f052a832ec92854dc09a3adbcb76ba73a689454c/packages/office-ui-fabric-react/src/components/ContextualMenu/ContextualMenu.base.tsx#L720-L732

Can we revisit this decision? The stated justification of

This is consistent with Office application in the app.

and

Seems like this is consistent with windows file explorer and the menus in browsers as well.

ignore conventional differences between native Windows controls and web (not to mention the fact that macOS does _not_ close menus on modifier keys; typically alt/option reveals more advanced menu options and command does nothing)—crucially, web users need to be able to open links in new tabs by holding ctrl/command, so this behavior is super frustrating when someone is hovering a menu item that behaves as a link, and they think “I’d like to open this page in a new tab,” hold ctrl/command, and the menu disappears.

[dzearing]

@jspurlin @christiango This is particularly gross and probably should be revisited.

Could we not do this? At least for macos command key. I 100% agree with the comments above; this feels overreaching.

[dzearing]

I've assigned to you @aneeshack4 but first lets get consensus before addressing anything here.

[dzearing]

Confirmed with @jspurlin that undoing this would be ok.

[jspurlin]

Just a note @dzearing, I'm fine with scoping this so that only option/alt can be used to expand/collapse menus. If we removed it completely, how would a user be able to expand a comboBox or splitButton?

[dzearing]

Aneesha if you've already started on this, feel free to steel back, otherwise seems like a simple issue for @ecraig12345 to take a shot at.

[aneeshack4]

I haven't gotten a chance to start on this so @ecraig12345, if you want go for it!

[ecraig12345]

Could someone please clarify exactly what the requested fix is here? Is it to add a Mac-specific case where pressing Alt/Opt or Command (without down arrow or other keys) should not close the menu? Or to revert some/all of @jspurlin's change from #5207 (and if so, which parts)?

Also, if we're adding a Mac-specific case, how should the user agent check be handled? Currently the only place I see a user agent check for Mac is in KeytipLayer, but since we're adding a second check I wonder if it's worth moving to a utility.

[msft-github-bot]

:tada:This issue was addressed in #7061, which has now been successfully released as @uifabric/[email protected].:tada:

Handy Links:

• Release Notes
• Official NPM Release

[msft-github-bot]

:tada:This issue was addressed in #7061, which has now been successfully released as [email protected].:tada:

Handy Links:

• Release Notes
• Official NPM Release
• Test the release with Developer Demo Site