MacViews: mainMenu keyEquivalents don't work in Tab-Modal dialogs |
|||
Issue descriptionChrome Version : 58.0.3004.3 OS Version: OS X 10.12.3 They work fine in bubbles. But they don't in Tab-Modals. Maybe the key ends up on the overlay window and gets lost :/ This includes stuff like Cmd+z (undo), so that's bad. See also Issue 19792 "OSX: Global Keyboard shortcuts don't work when http auth dialog is active" Actually, for MacViews, *Global* Keyboard shortcuts are working. It's just the MainMenu ones that are not. (For Cocoa, some MainMenu stuff works, like Cmd+z, but not browser commands like Cmd+t) What steps will reproduce the problem? 1. chrome://flags/#secondary-ui-md enabled 2. https://httpbin.org/basic-auth/user/passwd 3. Type something, press Cmd+z What is the expected result? Should undo What happens instead of that? Doesn't UserAgentString: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3004.3 Safari/537.36 It's possible fixing this also fixes Issue 545442
,
Apr 12 2017
tapted: are you likely to be able to take a peek at this soon?
,
Apr 13 2017
yup
,
Apr 21 2017
,
Apr 22 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/a9e14964b037e70a90936908b8740d50b73e3b73 commit a9e14964b037e70a90936908b8740d50b73e3b73 Author: tapted <tapted@chromium.org> Date: Sat Apr 22 21:56:58 2017 Mac: Never dispatch keyEquivalents to the web contents if the window is not Key. When pressing a hotkey on Mac, AppKit asks pretty much everything in the UI if it wants to handle it. When a dialog is showing, we want the browser window to handle commands such as "change tabs". So events can propagate up to a browser window, but WebContents shouldn't see events when a dialog is active. In fact, the WebContents doesn't: the dialog machinery invokes RenderWidgetHostImpl::SetIgnoreInputEvents(..) while the dialog is showing, but RenderWidgetHostImpl ignores the event only *after* [RenderWidgetHostViewCocoa performKeyEquivalent:] has returned NO. Ignored events are not sent over IPC, so they are never sent back "unhandled" to be redispatched. So this prevents other parts of the UI (such as the mainMenu) from participating in event dispatch - the event is lost. This became an issue when dialogs started doing their own command propagation rather than hooking the -[NSWindow _sharesParentKeyState] SPI which causes a bunch of other weird issues. To fix, have RenderWidgetHostViewCocoa return NO immediately if its window is not the keyWindow. It currently just checks if it's the firstResponder in its window. BUG= 692377 TEST=On Mac, Enable chrome://flags/#secondary-ui-md, Navigate to https://httpbin.org/basic-auth/user/passwd, cancel the dialog, then refresh the page (dialog should show a second time). Type some text and press Cmd+x to 'Cut' - text should be cut and Edit menu should flash. Review-Url: https://codereview.chromium.org/2834763002 Cr-Commit-Position: refs/heads/master@{#466553} [modify] https://crrev.com/a9e14964b037e70a90936908b8740d50b73e3b73/content/browser/renderer_host/render_widget_host_view_mac.mm [modify] https://crrev.com/a9e14964b037e70a90936908b8740d50b73e3b73/content/browser/renderer_host/render_widget_host_view_mac_unittest.mm
,
Apr 25 2017
tapted@: is this fixed now? It seems fixed when I experiment with it, and the test listed in that TEST= passes.
,
Apr 30 2017
|
|||
►
Sign in to add a comment |
|||
Comment 1 by tapted@chromium.org
, Feb 28 2017