MacViews: Can't focus textfields after switching away from a tab with a toolkit-views Tab-Modal dialog |
|||||
Issue descriptionChrome Version : 51.0.2700.0 OS Version: OS X 10.11.4 What steps will reproduce the problem? 1. Enable chrome://flags/#app-info-dialog , restart if you need to (alternative: #mac-views-dialogs and http-auth) 2. Go to chrome://extensions and click "Details" on some stuff 3. Open a new tab (or switch to an existing one) 4. Try to focus/type in a textfield What is the expected result? Should work. What happens instead of that? Doesn't. The problem is that as of r372036 the tab-modal dialog shares its key state with the parent window. This allows it to keep the browser window traffic lights "lit" the way window-modal sheets do. So it's the "correct" behaviour while on that tab. But when switching tabs, the parent window should get back exclusive key state. Note that tab-modals in Cocoa Chrome (try, e.g., Print Preview ⌘p) don't keep the traffic lights lit (ideally they would, but maybe this is why). Bubbles *do* share key state, but they are more ephemeral. I think one aspect of this is that when tab-switching away from a tab, the tab-modals are hidden via their alpha channel rather than simply closed/ordered out. There's a reason for that, but maybe there's a better fix for that reason. Alternatively, we could just lose traffic light "lit" status with tab-modals the way Cocoa Chrome does.
,
Apr 14 2016
,
Apr 14 2016
bulk-tagging Phase2 for M-53
,
Apr 20 2016
,
May 9 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/1b0d712e570d6800634910954d6a6690b1ae5d17 commit 1b0d712e570d6800634910954d6a6690b1ae5d17 Author: tapted <tapted@chromium.org> Date: Mon May 09 22:31:37 2016 Mac: Use a "less" private API for keeping traffic lights lit while bubbles are showing The approach: Rather than overriding -[NSWindow _sharesParentKeyState] on the child, override -[NSWindow hasKeyAppearance] on the parent. This is used, e.g., by WebKit since http://wkrev.com/164173. It doesn't have an underscore on the front which I guess is nice. After this, we should be able to phase out the overrides of the slightly "more" private API -_sharesParentKeyState. info_bubble_window.mm still uses this, and it causes a lot of complex interactions with hotkeys and dialog dismissal. Leave this for a follow-up since it will be tricky to ensure there are no regressions while unwinding the existing workarounds for _sharesParentKeyState weirdness. This would also give a nice way to keep traffic lights lit when WebModal dialogs are showing. This isn't currently done, and would make their behaviour more consistent with native sheets. However, WebModals are actually *grand*-children of the Cocoa browser window and have other complications. Leave that for a follow-up as well. BUG= 602846 , 603881 Review-Url: https://codereview.chromium.org/1955343002 Cr-Commit-Position: refs/heads/master@{#392448} [modify] https://crrev.com/1b0d712e570d6800634910954d6a6690b1ae5d17/chrome/browser/ui/cocoa/chrome_browser_window.mm [modify] https://crrev.com/1b0d712e570d6800634910954d6a6690b1ae5d17/ui/views/cocoa/native_widget_mac_nswindow.mm [modify] https://crrev.com/1b0d712e570d6800634910954d6a6690b1ae5d17/ui/views/widget/native_widget_mac_interactive_uitest.mm
,
May 9 2016
|
|||||
►
Sign in to add a comment |
|||||
Comment 1 by tapted@chromium.org
, Apr 14 2016