Intermittent failure in a11y/accessible/test_nsIAccessible_focus.html | Focus wasn't received for element with ID aria-link.

RESOLVED WORKSFORME

Status

()

defect
RESOLVED WORKSFORME
9 years ago
7 years ago

People

(Reporter: Ehsan, Assigned: davidb)

Tracking

({intermittent-failure})

Trunk
x86
macOS
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Reporter

Description

9 years ago
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1276882231.1276883593.21429.gz
Rev3 Fedora 12 mozilla-central opt test mochitest-other on 2010/06/18 10:30:31

11306 INFO TEST-START | chrome://mochikit/content/a11y/accessible/test_nsIAccessible_focus.html
11307 INFO TEST-PASS | chrome://mochikit/content/a11y/accessible/test_nsIAccessible_focus.html | before wait for focus -- loaded: loading active window: ([object ChromeWindow]) chrome://browser/content/browser.xul focused window: ([object XPCNativeWrapper [object Window]]) chrome://mochikit/content/a11y/accessible/test_nsIAccessible_focus.html desired window: ([object Window]) chrome://mochikit/content/a11y/accessible/test_nsIAccessible_focus.html child window: ([object XPCNativeWrapper [object Window]]) chrome://mochikit/content/a11y/accessible/test_nsIAccessible_focus.html docshell visible: true
11308 INFO TEST-PASS | chrome://mochikit/content/a11y/accessible/test_nsIAccessible_focus.html | must wait for load
11309 INFO TEST-PASS | chrome://mochikit/content/a11y/accessible/test_nsIAccessible_focus.html | already focused
11310 INFO TEST-PASS | chrome://mochikit/content/a11y/accessible/test_nsIAccessible_focus.html | maybe run tests <load:false, focus:true> -- loaded: loading active window: ([object ChromeWindow]) chrome://browser/content/browser.xul focused window: ([object XPCNativeWrapper [object Window]]) chrome://mochikit/content/a11y/accessible/test_nsIAccessible_focus.html desired window: ([object Window]) chrome://mochikit/content/a11y/accessible/test_nsIAccessible_focus.html child window: ([object XPCNativeWrapper [object Window]]) chrome://mochikit/content/a11y/accessible/test_nsIAccessible_focus.html docshell visible: true
11311 INFO TEST-PASS | chrome://mochikit/content/a11y/accessible/test_nsIAccessible_focus.html | waitForEvent called <type:load, target[object HTMLDocument]> -- loaded: complete active window: ([object ChromeWindow]) chrome://browser/content/browser.xul focused window: ([object XPCNativeWrapper [object Window]]) chrome://mochikit/content/a11y/accessible/test_nsIAccessible_focus.html desired window: ([object Window]) chrome://mochikit/content/a11y/accessible/test_nsIAccessible_focus.html child window: ([object XPCNativeWrapper [object Window]]) chrome://mochikit/content/a11y/accessible/test_nsIAccessible_focus.html docshell visible: true
11312 INFO TEST-PASS | chrome://mochikit/content/a11y/accessible/test_nsIAccessible_focus.html | maybe run tests <load:true, focus:true> -- loaded: complete active window: ([object ChromeWindow]) chrome://browser/content/browser.xul focused window: ([object XPCNativeWrapper [object Window]]) chrome://mochikit/content/a11y/accessible/test_nsIAccessible_focus.html desired window: ([object Window]) chrome://mochikit/content/a11y/accessible/test_nsIAccessible_focus.html child window: ([object XPCNativeWrapper [object Window]]) chrome://mochikit/content/a11y/accessible/test_nsIAccessible_focus.html docshell visible: true
11313 ERROR TEST-UNEXPECTED-FAIL | chrome://mochikit/content/a11y/accessible/test_nsIAccessible_focus.html | Focus wasn't received for element with ID aria-link.
11314 INFO TEST-PASS | chrome://mochikit/content/a11y/accessible/test_nsIAccessible_focus.html | No focused state for element with ID aria-link.
11315 INFO TEST-PASS | chrome://mochikit/content/a11y/accessible/test_nsIAccessible_focus.html | Focus wasn't received for element with ID aria-link2.
11316 INFO TEST-PASS | chrome://mochikit/content/a11y/accessible/test_nsIAccessible_focus.html | No focused state for element with ID aria-link2.
11317 INFO TEST-PASS | chrome://mochikit/content/a11y/accessible/test_nsIAccessible_focus.html | Focus wasn't received for element with ID link.
11318 INFO TEST-PASS | chrome://mochikit/content/a11y/accessible/test_nsIAccessible_focus.html | No focused state for element with ID link.

This was first seen on mozilla-central on this changeset <http://hg.mozilla.org/mozilla-central/rev/d4156799e66a> but bz has seen this on the try server without his patches.
Comment hidden (Legacy TBPL/Treeherder Robot)
Comment hidden (Legacy TBPL/Treeherder Robot)
Comment hidden (Legacy TBPL/Treeherder Robot)
Comment hidden (Legacy TBPL/Treeherder Robot)
So this is sort of a regression from bug 563327 in that it became more likely to fail.

The structure of the test is this:

28       gFocusManager.listenElement(linkAcc, ID, doTest2);
29       linkAcc.takeFocus();

where listenElement does:

68         registerA11yEventListener(nsIAccessibleEvent.EVENT_FOCUS, this);
...
76         window.setTimeout(
77           function(aFocusMgr)
78           {
79             aFocusMgr.checkWasFocusHandled();
80           }, 0, this);

and checkWasFocusHandled checks that the EVENT_FOCUS fired.

Now what this means is that we have a race between the async EVENT_FOCUS firing and the async timeout execution.  The former presumably happens when we flush the event queue. The latter happens whenever it happens; it's actually rather complicated.  But it's not likely to happen less than 10ms after the setTimeout call, whereas the queue flush _used_ to be likely to thus happen and is now less likely to do.

Ideally, we'd run the checkWasFocusHandled after the a11y queue flush happens, but we don't really have a way to detect that, right?

The other option is to do the check off an async timer from the notification I plan to add in bug 569520.
Blocks: 563327
I just pushed http://hg.mozilla.org/mozilla-central/rev/0bb70936ae1c to bump the timeout for now, in hopes of reducing incidence of orange.
Comment hidden (Legacy TBPL/Treeherder Robot)
(In reply to comment #7)

Makes sense.

> Ideally, we'd run the checkWasFocusHandled after the a11y queue flush happens,
> but we don't really have a way to detect that, right?

Not currently.

> The other option is to do the check off an async timer from the notification I
> plan to add in bug 569520.

Ok not sure what notification you will add there. It might make sense.

(In reply to comment #8)
> I just pushed http://hg.mozilla.org/mozilla-central/rev/0bb70936ae1c to bump
> the timeout for now, in hopes of reducing incidence of orange.

Thanks.
(In reply to comment #10)
> > The other option is to do the check off an async timer from the notification I
> > plan to add in bug 569520.
> 
> Ok not sure what notification you will add there.

One that will tell script when a refresh is in process (and the refresh will make a sync call to the queue flush in a11y).
(In reply to comment #11)
> (In reply to comment #10)
> > > The other option is to do the check off an async timer from the notification I
> > > plan to add in bug 569520.
> > 
> > Ok not sure what notification you will add there.
> 
> One that will tell script when a refresh is in process (and the refresh will
> make a sync call to the queue flush in a11y).

OK great!
Comment hidden (Legacy TBPL/Treeherder Robot)
Comment hidden (Legacy TBPL/Treeherder Robot)
Comment hidden (Legacy TBPL/Treeherder Robot)
Comment hidden (Legacy TBPL/Treeherder Robot)
Comment hidden (Legacy TBPL/Treeherder Robot)
Comment hidden (Legacy TBPL/Treeherder Robot)
Comment hidden (Legacy TBPL/Treeherder Robot)
Comment hidden (Legacy TBPL/Treeherder Robot)
Comment hidden (Legacy TBPL/Treeherder Robot)
Comment hidden (Legacy TBPL/Treeherder Robot)
Comment hidden (Legacy TBPL/Treeherder Robot)
Comment hidden (Legacy TBPL/Treeherder Robot)
I'll own this for now, we should be able to check off of bz's async timer :)
Assignee: nobody → bolterbugz
no reports during half of year, close as worksforme
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → WORKSFORME
Whiteboard: [orange]
You need to log in before you can comment on or make changes to this bug.