Focus wonkiness when laptop lid closed, reopen and log back in |
|||||||||
Issue descriptionSteps: 1. Load attached file with or without screen reader such as NVDA or JAWS 2. Focus a character in the contenteditable (note, also occurs if user is focused in an <input> or <textarea>) 3. Close lid, wait, reopen, log back in What happens: 1. A different window is in the foreground, but the Chrome window still thinks it's focused (as evidenced by a blinking caret) 2. Alt+tab back to Chrome Window does not result in correct focus events, and screen reader (if present) is confused (left/right arrow in contenteditable does not cause character echo anymore, requires page refresh). Expected: Same Chrome Window is in foreground Left/right arrow in contenteditable echoes character if screen reader is on Notes: - When verifying this bug, please be sure the screen reader character echo works properly as well. - Requires actual lid closure. Putting PC to sleep or logging out does not repro the bug. - Does not reproduce in Firefox. - The accessibility code is informed that the Chrome window is blurred then focused, even though another non-Chrome window has focus. Alt+tabbing to Chrome does not call into BrowserAccessibilityManager::OnWindowFocused() as it should.
,
Oct 16
,
Oct 16
,
Oct 16
,
Oct 16
,
Oct 16
,
Oct 16
,
Oct 16
,
Oct 17
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/25f06cebba0d2b43bbea51e04e1800c485eb5132 commit 25f06cebba0d2b43bbea51e04e1800c485eb5132 Author: Aaron Leventhal <aleventhal@chromium.org> Date: Wed Oct 17 00:04:54 2018 Fix focus when laptop lid closed and reopened When a Windows laptop lid is reopened, a redundant call into HWNDMessageHandler::OnDwmCompositionChanged() calls into FrameTypeChanged() and then PerformDwmTransition() which hides and shows the current window in order to fix a theme change rendering issue. For some reason this puts Chrome into a strange focus state, where another desktop Window is shown at the top of the Z order, but the Chrome window still thinks it is focused, resulting in strange behavior and rendering issues. This fixes the issue by filtering out redundant theme change messages, where DWM composition did not actually change. Bug: 895855 Change-Id: Id6badb462a1011e246810c885acc173cbbce387e Reviewed-on: https://chromium-review.googlesource.com/c/1283837 Reviewed-by: Scott Violet <sky@chromium.org> Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org> Commit-Queue: Aaron Leventhal <aleventhal@chromium.org> Cr-Commit-Position: refs/heads/master@{#600201} [modify] https://crrev.com/25f06cebba0d2b43bbea51e04e1800c485eb5132/ui/views/win/hwnd_message_handler.cc [modify] https://crrev.com/25f06cebba0d2b43bbea51e04e1800c485eb5132/ui/views/win/hwnd_message_handler.h
,
Oct 17
,
Oct 18
Tested this issue on Windows 10 using HP EliteBook laptop on the build without fix 71.0.3561.0 and unable to reproduce the issue by following the below steps. 1. Launched Chrome and opened the attached html file and focussed on a character in the 2nd paragraph. 2. Closed the lid of the laptop -> reopened it -> logged in back and can observe that the same window is in the foreground and the focus is still at the same place before the lid is closed. Attached is the screen cast for reference. aleventhal@ Request you to check and confirm if anything is missed from our end in verifying the issue and help us in verifying the fix on the latest M-72 build. Thanks. |
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by aleventhal@chromium.org
, Oct 16