Fix dialogs losing focus while using ⌘` to switch windows.
- If a browser window becomes key while a dialog is up and the web content is first responder, give focus to the dialog. - If the web content *loses* first responder while the dialog is key, make the browser window key. This makes sure that clicking the omnibox or typing ⌘L, for instance, focuses the browser window. The final version of this change is incomplete: The separation between "focused" ("the web content is focused within its window") and "active" ("the web content's window is the active window") is mostly an illusion because it only exists on Mac and I kept running into cases where it breaks down (e.g. setting "focused" implicitly sets "active" deep inside WebViewImpl). A bunch of tests also check that certain functions and IPCs happen in a certain order, so fiddling with anything just breaks a bunch of tests in ways that don't map to real-world behavior. Now isn't the right time to mess with that, especially in Cocoa code, so this leaves one case unfixed: - If a dialog becomes key some other way, make sure that the web content is first responder in its parent window (so that focus returns to the web content on dismissing the dialog, and no other views have first responder appearance). I filed https://crbug.com/821931 to track it. Bug: 658405 Change-Id: I7ec11568d860e7371f552baa44a0d6b45db6dc22 Reviewed-on: https://chromium-review.googlesource.com/935424 Commit-Queue: Sidney San Martín <sdy@chromium.org> Reviewed-by:Trent Apted <tapted@chromium.org> Reviewed-by:
Robert Sesek <rsesek@chromium.org> Reviewed-by:
Avi Drissman <avi@chromium.org> Cr-Commit-Position: refs/heads/master@{#543170}
Showing
Please register or sign in to comment