[Extensions API] [Regression] chrome.windows.Window.focused is wrong when a menu pops up
Reported by
hrg....@gmail.com,
Jan 17
(6 days ago)
|
||||||||||
Issue descriptionChrome Version: Chrome 71 OS Version: Windows 7, Windows 10 Did it work before: Yes, up until Chrome 70 it worked fine. What steps will reproduce the problem? 1. Load the unpacked extension (file attached). 2. Inspect the extension's "background page" with DevTools. 3. Inside DevTools, select the "console" tab. 4. You'll see the log message "Focused state: true" indicating the value of the chrome.windows.Window.focused property every second. 5. Keep the DevTools window in a visible part of the screen. You'll need to look at it in step 7. 6. Click on the "Profile" toolbar button (the one to the left of the "3 dots" button). The profile menu will pop up. 7. Now look at the DevTools console. The log message changed to "Focused state: false". What is the expected result? chrome.windows.Window.focused should return "true" when a floating menu pops up, as is the case with all previous Chrome versions. The window maintains focus in those cases.
,
Jan 17
(5 days ago)
Able to reproduce this issue on Windows 10 and Mac OS 10.13.6 on the latest Stable 71.0.3578.98 and latest Canary 73.0.3673.0. Issue is not observed on Ubuntu 17.10. This issue is observed from M-60 chrome builds. Attached is the screen cast for reference. hrg.wea@ Request you to check the screen cast and confirm the behavior in M-60 chrome build. Thanks..
,
Jan 17
(5 days ago)
I conducted a more exhaustive test on different Chrome versions and Windows versions. For each version, I tested the value of the "chrome.windows.Window.focused" property for 13 different popup menus. The results are in the attached image. Per your request, as shown in the results, I can confirm that on Windows 10, Chrome 60, the "profile menu" FAILS the test. Also, on Chrome 71 (on any Windows version), 6 out of 13 test cases fail the test.
,
Jan 17
(5 days ago)
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jan 18
(5 days ago)
hrg.wea@ Thanks for the update. As per comment #3, as the issue is observed on M-60 chrome builds, this is a Non-Regression issue. Marking this issue as Untriaged for further updates from Dev. Thanks..
,
Jan 18
(4 days ago)
This is interesting. I could understand either value here for focus (though I'd be inclined to say that if any child window is focused, the parent should be considered focused as well), but we should certainly at least be consistent. +robliao@. Rob, we currently retrieve the focus state from the window's IsActive() function. Is it expected that this is true for some kinds of menus/popups, but not others? Would this potentially have an impact outside of extensions? [1] https://chromium.googlesource.com/chromium/src/+/5f0fb8c9021d25d1fadc1ae3706b4790dbcded5a/chrome/browser/extensions/extension_tab_util.cc#438
,
Jan 18
(4 days ago)
,
Jan 19
(4 days ago)
For me, the situation is clear. The focused state of a window is indicated by: - Its title bar color - Its taskbar button - The fact that the window is capturing the keyboard input When a popup menu appears (all 13 cases I tested), the window keeps being the focused one, by those 3 criteria. So, naturally, the property chrome.windows.Window.focused should reflect that state. There's a mismatch between the actual focused state of the window and the state reported by Window.focused. |
||||||||||
►
Sign in to add a comment |
||||||||||
Comment 1 by viswa.karala@chromium.org
, Jan 17 (6 days ago)