Closed Bug 1784752 Opened 3 years ago Closed 2 years ago

Intermittent accessible/tests/browser/events/browser_test_panel.js | single tracking bug

Categories

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

Product:
Core
Component:
Disability Access APIs
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
112 Branch
Tracking Flags:
Tracking Status
firefox112 --- fixed

People

(Reporter: jmaher, Assigned: Jamie)

References

Details

(Keywords: intermittent-failure, intermittent-testcase, Whiteboard: [stockwell disable-recommended])

Attachments

(2 files)

Bug 1784752 part 1: Reset the mutation events queue and Accessible state bits before firing any mutation events.
48 bytes, text/x-phabricator-request
Details | Review
Bug 1784752 part 2: Disable A11YLOG for accessible/tests/browser/events.
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 1784752

There have been 34 total failures in the last 7 days, recent failure log.
Affected platforms are:

  • linux1804-64-asan-qr
  • linux1804-64-qr
  • windows7-32-qr
[task 2023-02-08T20:48:55.927Z] 20:48:55     INFO - TEST-PASS | accessible/tests/browser/events/browser_test_panel.js | Popup panel is associated with the chrome window - 
[task 2023-02-08T20:48:55.927Z] 20:48:55     INFO - Buffered messages finished
[task 2023-02-08T20:48:55.928Z] 20:48:55     INFO - TEST-UNEXPECTED-FAIL | accessible/tests/browser/events/browser_test_panel.js | Test timed out - 
[task 2023-02-08T20:48:55.939Z] 20:48:55     INFO - GECKO(1581) | MEMORY STAT | vsize 20984022MB | residentFast 1582MB
[task 2023-02-08T20:48:55.940Z] 20:48:55     INFO - TEST-OK | accessible/tests/browser/events/browser_test_panel.js | took 90463ms
Flags: needinfo?(jteh)
Whiteboard: [stockwell needswork:owner]

There have been 67 total failures in the last 7 days, recent failure log.
Affected platforms are:

  • linux1804-64-asan-qr
  • linux1804-64-qr

I'm looking into this.

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

Here's what's happening:

  1. We process and fire mutation events directly from the queue.
  2. When we fire an event, that enters JS.
    • I'm not entirely certain how this happens because I can't get a full stack with a debugger or anything else I've tried due to the JS frames. It could be because of the XPCOM observer or it could be because A11YLOG is enabled for those tests and that is somehow entering JS, which is certainly possible with XUL.
  3. JS code runs which hides the panel.
  4. We call QueueMutationEvent.
  5. Because we are still processing the events (1), we haven't cleaned up the previous mutation event queue or the various event target bits (ShowEventTarget, etc.) on the Accessibles.
  6. As a result, we drop the hide event because the show event flag is still set on the Accessible.
  7. The test times out because the hide event never gets fired.

Disabling A11YLOG for those tests (which we should do anyway - that was only meant to be temporary) seems to fix this locally, which suggests logging is probably the re-entry culprit in this case. However, I still think this could be a potential problem regardless.

This was only ever meant to be temporary, but I forgot to remove it.

I have a patch up here. I spoke to the reviewer this morning and it should get reviewed soon.

Pushed by jteh@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/ff8b2808810a part 1: Reset the mutation events queue and Accessible state bits before firing any mutation events. r=eeejay

Did you intend to land Part 2 also?

Flags: needinfo?(jteh)

Uh, yes, I did. That said, there won't be bustage if part 1 lands without part 2.

Flags: needinfo?(jteh)

I've queued landing of part 2.

Pushed by jteh@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/8b5f11edd63c part 2: Disable A11YLOG for accessible/tests/browser/events. r=eeejay

FWIW, this still fails frequently on Windows 10.

Terrific. I guess it must be a different failure somehow, but I'd need to see a log for it to know for sure.

🧞‍♂️

This is definitely a different failure. For some reason, vsync doesn't get disabled, perhaps suggesting that the a11y refresh driver is still running... or maybe some other refresh driver.

Whiteboard: [stockwell disable-recommended]

https://hg.mozilla.org/mozilla-central/rev/ff8b2808810a
https://hg.mozilla.org/mozilla-central/rev/8b5f11edd63c

Status: NEW → RESOLVED
Closed: 2 years ago
status-firefox112: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 112 Branch
See Also: → 1818994
Regressions: 1824064
No longer depends on: 1703620
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: