Issue 1028843 in chromium: Windows global focus event is set to Document by nothing is focused
20 views
Skip to first unread message
benjamin.beaudry via monorail
Nov 26, 2019, 9:49:48 PM11/26/19
to dom...@chromium.org
Status: Untriaged
Owner: ----
CC: dom...@chromium.org
Components: Blink>DOM
Pri: 3
Type: Bug
New issue 1028843 by benjamin...@microsoft.com: Windows global focus event is set to Document by nothing is focused
https://bugs.chromium.org/p/chromium/issues/detail?id=1028843
Chrome Version: 80.0.3975
OS: Win10
On Windows, there is this global focus event that is shared between all apps. It is the equivalent of chromium "focusin" event. There is no equivalence to our "focusout" event. The global focus event should only be dispatched when an element gets user focus, such as a text field or any other focusable element.
When we call Document::ClearFocusedElement(), the focused element is set to nullptr and a "focusin" event is fired on the document (by default). We also dispatch a global focus event as if the user had selected the document. In reality, the user didn't really selected the document - the currently focused element just lost focus.
Windows UI Automation listens to this global focus event to announce the focused element. When a focusable element such as a text field loses focus because we click outside of the text box, a user using Narrator will hear "Document" as the global focus event fired will have the target on the document. This behavior is different than the one in Edge and multiple other Windows apps.
The worst part of the issue occurs when a user is using Narrator to navigate by word in a web page. When the user will leave a text field to read the next word in a non-editable paragraph, Chromium will emit a focus global event targeting the document and Narrator, instead of announcing the next word as expected, will announce "Document".
Using the accEvents tool on Windows 10, we can see that a focus event is fired on the document in Chromium and that none is fired on other Windows apps.
What steps will reproduce the problem?
(1) Run Chromium with --enable-experimental-ui-automation on Win10.
(2) Launch the attached file ("input.html").
(3) Click inside the input text field and then click outside, somewhere on the document where there is no element.
What is the expected result?
When clicking inside the element, Narrator should announce the "abc: edit".
When clicking outside, Narrator shouldn't say anything.
What happens instead?
When clicking outside the element, Narrator announces "Document".
You might encounter some bugs trying to test this. For example, text navigation with UIA doesn't work as expected with inputs for now. I have a change in progress fixing it. https://crrev.com/c/1937858
Attachments:
input.html 216 bytes
--
You received this message because:
1. You were specifically CC'd on the issue
You may adjust your notification preferences at:
https://bugs.chromium.org/hosting/settings
Reply to this email to add a comment or make updates.
Owner: ----
CC: dom...@chromium.org
Components: Blink>DOM
Pri: 3
Type: Bug
New issue 1028843 by benjamin...@microsoft.com: Windows global focus event is set to Document by nothing is focused
https://bugs.chromium.org/p/chromium/issues/detail?id=1028843
Chrome Version: 80.0.3975
OS: Win10
On Windows, there is this global focus event that is shared between all apps. It is the equivalent of chromium "focusin" event. There is no equivalence to our "focusout" event. The global focus event should only be dispatched when an element gets user focus, such as a text field or any other focusable element.
When we call Document::ClearFocusedElement(), the focused element is set to nullptr and a "focusin" event is fired on the document (by default). We also dispatch a global focus event as if the user had selected the document. In reality, the user didn't really selected the document - the currently focused element just lost focus.
Windows UI Automation listens to this global focus event to announce the focused element. When a focusable element such as a text field loses focus because we click outside of the text box, a user using Narrator will hear "Document" as the global focus event fired will have the target on the document. This behavior is different than the one in Edge and multiple other Windows apps.
The worst part of the issue occurs when a user is using Narrator to navigate by word in a web page. When the user will leave a text field to read the next word in a non-editable paragraph, Chromium will emit a focus global event targeting the document and Narrator, instead of announcing the next word as expected, will announce "Document".
Using the accEvents tool on Windows 10, we can see that a focus event is fired on the document in Chromium and that none is fired on other Windows apps.
What steps will reproduce the problem?
(1) Run Chromium with --enable-experimental-ui-automation on Win10.
(2) Launch the attached file ("input.html").
(3) Click inside the input text field and then click outside, somewhere on the document where there is no element.
What is the expected result?
When clicking inside the element, Narrator should announce the "abc: edit".
When clicking outside, Narrator shouldn't say anything.
What happens instead?
When clicking outside the element, Narrator announces "Document".
You might encounter some bugs trying to test this. For example, text navigation with UIA doesn't work as expected with inputs for now. I have a change in progress fixing it. https://crrev.com/c/1937858
Attachments:
input.html 216 bytes
--
You received this message because:
1. You were specifically CC'd on the issue
You may adjust your notification preferences at:
https://bugs.chromium.org/hosting/settings
Reply to this email to add a comment or make updates.
benjamin.beaudry via monorail
Nov 26, 2019, 9:53:25 PM11/26/19
to dom...@chromium.org
Updates:
Cc: kbab...@microsoft.com ra...@microsoft.com
Comment #1 on issue 1028843 by benjamin...@microsoft.com: Windows global focus event is set to Document by nothing is focused
https://bugs.chromium.org/p/chromium/issues/detail?id=1028843#c1
(No comment was entered for this change.)
Cc: kbab...@microsoft.com ra...@microsoft.com
Comment #1 on issue 1028843 by benjamin...@microsoft.com: Windows global focus event is set to Document by nothing is focused
https://bugs.chromium.org/p/chromium/issues/detail?id=1028843#c1
(No comment was entered for this change.)
masonfreed via monorail
Dec 3, 2019, 7:06:30 PM12/3/19
to dom...@chromium.org
Updates:
Components: -Blink>DOM UI>Accessibility
Comment #2 on issue 1028843 by mason...@chromium.org: Windows global focus event is set to Document by nothing is focused
https://bugs.chromium.org/p/chromium/issues/detail?id=1028843#c2
Just to confirm - you are saying that only with the --enable-experimental-ui-automation flag enabled, an extra focusin event is fired at the document object when any control is blurred. But this does not happen without the experimental ui automation flag enabled. (I confirmed the non-enabled case with the attached repro, and things there look good to me - no extra focusin event. This is your example from comment #0 with a log of the events fired at document.)
Based on the above, I'm changing the component to UI>Accessibility, hopefully that's the right place to file this.
Attachments:
bug1028843_focusin.html 1.1 KB
Components: -Blink>DOM UI>Accessibility
Comment #2 on issue 1028843 by mason...@chromium.org: Windows global focus event is set to Document by nothing is focused
https://bugs.chromium.org/p/chromium/issues/detail?id=1028843#c2
Just to confirm - you are saying that only with the --enable-experimental-ui-automation flag enabled, an extra focusin event is fired at the document object when any control is blurred. But this does not happen without the experimental ui automation flag enabled. (I confirmed the non-enabled case with the attached repro, and things there look good to me - no extra focusin event. This is your example from comment #0 with a log of the events fired at document.)
Based on the above, I'm changing the component to UI>Accessibility, hopefully that's the right place to file this.
Attachments:
bug1028843_focusin.html 1.1 KB
Reply all
Reply to author
Forward
0 new messages