Open Bug 1775684 Opened 3 years ago Updated 2 days ago

Intermittent accessible/tests/browser/e10s/browser_caching_states.js | single tracking bug

Categories

(Core :: Disability Access APIs, defect, P3)

Product:
Core
Component:
Disability Access APIs
Type:
defect

Tracking

()

Status:
REOPENED

People

(Reporter: jmaher, Assigned: Jamie)

References

Details

(Keywords: intermittent-failure, intermittent-testcase)

Attachments

(2 files)

Bug 1775684 part 1: Ignore frame visibility when caching focusable state for a11y.
48 bytes, text/x-phabricator-request
Details | Review
Bug 1775684 part 2: Don't create a DocAccessible if it doesn't exist yet when handling notifications for cache/tree updates.
48 bytes, text/x-phabricator-request
Details | Review
No description provided.

Additional information about this bug failures and frequency patterns can be found by running: ./mach test-info failure-report --bug 1775684

Severity: -- → S4

This is failing frequently: backfill and retriggers.
When the jobs are not failing with this, they tend to fail with Bug 1775689.

Hi James! Could you please take a look at this and maybe at the other bug also?
Thank you!

Flags: needinfo?(jteh)
Summary: Intermittent accessible/tests/browser/e10s/browser_caching_states.js | single tracking bug → Frequent accessible/tests/browser/e10s/browser_caching_states.js | single tracking bug

I'm looking into this, so taking.

This is happening because when we build the initial cache for the a11y tree, elements sometimes report as not focusable even though they should be focusable. In these cases, nsIFrame::IsFocusable returns false because PresShell::IsUnderHiddenEmbedderElement returns true. This only seems to happen in OOP iframes. I don't know why it's happening yet, though.

Assignee: nobody → jteh
Flags: needinfo?(jteh)

I've been digging into why IsUnderHiddenEmbedderElement returns true in this case, which is certainly odd. However, I'm realising this is a broader problem. You can easily reproduce this problem with an iframe that is deliberately initially set visibility: hidden. In that case, all of the Accessibles in the iframe document get cached as non-focusable.

See the code comment in LocalAccessible::BundleFieldsForCache for explanation.
Note that invisible frames in a visible document are removed from the a11y tree, so this change doesn't affect those.
This is only relevant for visible elements in an invisible document, since invisible OOP iframe documents do build an a11y tree.

We only use these notifications from layout to push cache updates.
If the DocAccessible doesn't exist yet, creating it is pointless since we can't push a cache update until the tree is built.
The correct data will be included in the initial cache push anyway.
Aside from pointless refresh ticks, this really shouldn't make any difference, since we don't build the initial tree until layout is ready anyway.
However, the only remotely relevant thing I can think of that's changed in the a11y code lately that might have caused a spike in these test failures is that bounds notifications might get fired earlier/more often from layout, potentially causing earlier creation of DocAccessibles.
Any change to timing might cause a shift in intermittent failures, and since this is wasteful anyway, we may as well fix it.

Attachment #9316033 - Attachment description: Bug 1775684 part 2: Don't create a DocAccessible if it doesn't exist yet when handling notifications for cache updates. → Bug 1775684 part 2: Don't create a DocAccessible if it doesn't exist yet when handling notifications for cache/tree updates.
Pushed by jteh@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/9ee4aeb05243 part 1: Ignore frame visibility when caching focusable state for a11y. r=morgan,emilio https://hg.mozilla.org/integration/autoland/rev/f007462e07ea part 2: Don't create a DocAccessible if it doesn't exist yet when handling notifications for cache/tree updates. r=morgan

https://hg.mozilla.org/mozilla-central/rev/9ee4aeb05243
https://hg.mozilla.org/mozilla-central/rev/f007462e07ea

Status: NEW → RESOLVED
Closed: 2 years ago
status-firefox111: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 111 Branch

This is still happening on autoland but not frequent: https://treeherder.mozilla.org/logviewer?job_id=405197184&repo=autoland

Status: RESOLVED → REOPENED
status-firefox111: fixed → ---
Resolution: FIXED → ---
Summary: Frequent accessible/tests/browser/e10s/browser_caching_states.js | single tracking bug → Intermittent accessible/tests/browser/e10s/browser_caching_states.js | single tracking bug
Target Milestone: 111 Branch → ---

This one (and probably failures before the spike) is a different failure which seems to occur at the point the document is loaded. I'm not sure why that happens yet.

See Also: → 1776049

https://wiki.mozilla.org/Bug_Triage#Intermittent_Test_Failure_Cleanup
For more information, please visit BugBot documentation.

Status: REOPENED → RESOLVED
Closed: 2 years ago → 6 months ago
Resolution: --- → INCOMPLETE

New failure instance: https://treeherder.mozilla.org/logviewer?job_id=491069474&repo=autoland

Status: RESOLVED → REOPENED
Resolution: INCOMPLETE → ---

https://wiki.mozilla.org/Bug_Triage#Intermittent_Test_Failure_Cleanup
For more information, please visit BugBot documentation.

Status: REOPENED → RESOLVED
Closed: 6 months ago → 3 months ago
Resolution: --- → INCOMPLETE

New failure instance: https://treeherder.mozilla.org/logviewer?job_id=509688673&repo=autoland

Status: RESOLVED → REOPENED
Resolution: INCOMPLETE → ---
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: