Don't fire focus events for RemoteAccessibles if the document isn't focused
Categories
(Core :: Disability Access APIs, defect)
Tracking
()
People
(Reporter: Jamie, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
I've seen cases where a document fires a focus event even though it's in the background. I don't know how to reproduce this, but it seems to happen most when a lot of tabs are loading; e.g. when restoring tabs after a browser restart. Just focusing something with a setTimeout and moving the tab to the background isn't enough to trigger this; the focus event isn't fired by the content process until the tab is activated.
One case where this is easier to reproduce is the recently used tab switcher. When releasing control so that the switcher is dismissed, a focus event from the old document is often fired before a focus event for the new document.
A possible solution to try is to ignore focus events in DocAccessibleParent if they aren't for the focused BrowsingContext. Particularly in the second case, it's possible that this won't work because the BrowsingContext actually was focused briefly at the time, but we can only try.
|
Reporter | |
Updated•2 years ago
|
|
|
Reporter | |
Comment 1•2 years ago
|
||
|
|
Reporter | |
Comment 2•2 years ago
|
||
(In reply to James Teh [:Jamie] from comment #0)
it seems to happen most when a lot of tabs are loading; e.g. when restoring tabs after a browser restart.
I haven't found a way to reproduce this.
One case where this is easier to reproduce is the recently used tab switcher. When releasing control so that the switcher is dismissed, a focus event from the old document is often fired before a focus event for the new document.
Ignoring focus events if the BrowsingContext isn't focused doesn't help this case. :( I guess the document really does remain focused for a short while after the tab switcher closes.
Given that this isn't helping anything, I'm closing this for now. I've attached the patch I wrote in case it's useful later.
Description
•