DocAccessible::IsLoadEventTarget doesn't behave as intended
Categories
(Core :: Disability Access APIs, task)
Tracking
()
Fission Milestone | Future |
People
(Reporter: Jamie, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(1 obsolete file)
IsLoadEventTarget is supposed to return false for iframe documents which are still loading, thus preventing doc load complete events from firing in this case. This was done many years ago because it apparently caused problems for screen readers:
// b) document load event on sub documents causes screen readers to act is if // entire page is reloaded.
However, this has been broken since e10s; i.e. we do fire doc load complete events for iframes, even if the parent doc is still loading. The reason is that IsLoadEventTarget checks if the parent nsIDocShellTreeItem is the root and assumes this means the document is a tab (top level) document. In the parent process, this is true because the root is always the chrome. However, in content processes, the root is the top level content document! That means we treat an iframe below a top level document as if it were a top level document.
I can fix this, but I think we should instead remove this "intended" behaviour and return true for iframes regardless of the parent's loading state, keeping the current "unintentional" behaviour in content processes:
- Our browser tests rely on doc load complete events from iframes.
- Mac wants AXLayoutComplete to be fired on iframes and we map that from doc load complete.
- We've been doing this since e10s (3+ years) and it doesn't seem to have hurt any screen readers, so presumably, this has been fixed in screen readers.
- This check can never work for OOP (Fission) iframes, since the parent document is in a different process and we thus can't query its loading state.
In short, this would just remove dead code so that it reflects what happens in reality. It does change the behaviour for iframes in the parent process, but those are pretty rare and we should really be consistent anyway between parent and content.
Reporter | ||
Comment 1•4 years ago
|
||
Chrome seems inconsistent here. It often fires doc load complete events for iframes, but it sometimes doesn't.
Reporter | ||
Comment 2•4 years ago
|
||
(In reply to James Teh [:Jamie] from comment #0)
- Our browser tests rely on doc load complete events from iframes.
Actually, this is only true for Fission iframes. So, reverting to the originally intended behaviour wouldn't break our tests... but I still think we should be consistent here.
Reporter | ||
Comment 3•4 years ago
|
||
This code has been broken in content processes since e10s; i.e. we currently fire doc load complete events for iframes, even if the parent doc is still loading.
Rather than returning to the pre-e10s behaviour, this check has been removed instead for several reasons:
- Mac wants AXLayoutComplete to be fired on iframes and we map that from doc load complete.
- We've been doing this since e10s (3+ years) and it doesn't seem to have hurt any screen readers, so presumably, this has been fixed in screen readers.
- This check can never work for OOP (Fission) iframes, since the parent document is in a different process and we thus can't query its loading state.
- The behaviour is currently inconsistent between parent process documents and content process documents. Removing this check makes it consistent.
Updated•4 years ago
|
Updated•4 years ago
|
Reporter | ||
Updated•4 years ago
|
Reporter | ||
Comment 4•4 years ago
|
||
(In reply to James Teh [:Jamie] from comment #0)
- This check can never work for OOP (Fission) iframes, since the parent document is in a different process and we thus can't query its loading state.
Blocking a11y-fission for this reason. However, note that this is purely about code correctness; the actual behaviour (despite the confusing code) is already what we want for Fission.
Comment 5•4 years ago
|
||
Marking it for Fission Future since the code is behaving correctly for Fission per comment 4.
Description
•