Closed Bug 1412401 Opened 7 years ago Closed 5 years ago

Intermittent accessible/tests/mochitest/events/docload/test_docload_root.html | Test timed out.

Categories

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

Product:
Core
Component:
Disability Access APIs
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla74
Tracking Flags:
Tracking Status
firefox-esr68 --- fixed
firefox72 --- wontfix
firefox73 --- fixed
firefox74 --- fixed

People

(Reporter: intermittent-bug-filer, Assigned: Jamie)

References

Details

(Keywords: intermittent-failure)

Attachments

(1 file)

Bug 1412401: accessible/tests/mochitest/events/docload/test_docload_root.html: Wait for focus event after opening the dialog.
(deleted), text/x-phabricator-request
Details

This failure is observed with high intermittence on ubuntu1804.

Push on try:
https://treeherder.mozilla.org/#/jobs?repo=try&group_state=expanded&tier=1%2C2%2C3&revision=92429c43262b9cf8b68388a8c46e536fbb95286f

It seems to only be intermittent on the linux1804-64/opt variant.

:Jamie - could you please pass the ni to someone that may able to take a look, or alternatively would it be acceptable to disable this test for linux64 && not debug?

To run this test using ubuntu1804 image, use mach try fuzzy --ubuntu-bionic and select test-linux64 jobs as normal.

Forgot to set ni.

Flags: needinfo?(jteh)

When this fails, it seems that focus doesn't return to the previous browser window when a dialog gets closed. While this ideally should work for a good user experience, because we're dealing with OS windows, it is somewhat dependent on OS factors outside of our control; e.g. the OS might focus some other window, especially if some other window opened at some point during our test run. I'm going to try to reproduce this locally to see what's happening, but failing that, I think we'll just need to disable this on affected builds for now. :(

(In reply to James Teh [:Jamie] from comment #44)

When this fails, it seems that focus doesn't return to the previous browser window when a dialog gets closed. While this ideally should work for a good user experience, because we're dealing with OS windows, it is somewhat dependent on OS factors outside of our control; e.g. the OS might focus some other window, especially if some other window opened at some point during our test run. I'm going to try to reproduce this locally to see what's happening, but failing that, I think we'll just need to disable this on affected builds for now. :(

Thanks for the context of this failure. As far as I know, I have disabled anything that may take the focus away from the test (eg. update dialogs) but it is possible I missed something.

If window focusing is something managed by the window manager or desktop environment, then the change to GNOME may also have had an effect. I've run into an inconsequential number of failures caused by the difference in window manager between ubuntu1804 and ubuntu1604.

Previously, when opening the dialog, we only waited for a reorder event.
This could mean we programmatically closed the dialog before it was ever focused.
That in turn would mean that focus would never be fired on the previous window when the dialog was closed, causing the close dialog test to time out.

Assignee: nobody → jteh
Status: NEW → ASSIGNED

(In reply to Edwin Takahashi (:egao, :etakahashi) from comment #47)

Thanks for the context of this failure. As far as I know, I have disabled anything that may take the focus away from the test (eg. update dialogs) but it is possible I missed something.

I was able to reproduce this locally. Digging further, I think there's a subtle timing change here which is exposing a problem in the test. My patch seems to fix the problem locally and I'm now testing on try.

I ran the a11y tests four times on try with this patch and they all succeeded, so I think we're good with this patch.

Pushed by mzehe@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/b9f97507c651 accessible/tests/mochitest/events/docload/test_docload_root.html: Wait for focus event after opening the dialog. r=MarcoZ

https://hg.mozilla.org/mozilla-central/rev/b9f97507c651

Status: ASSIGNED → RESOLVED
Closed: 5 years ago
status-firefox74: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla74
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: