Open Bug 845134 Opened 7 years ago Updated Last year

Intermittent focus/test_focusedChild.html | Test timed out.

Categories

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

x86
Windows XP
defect

Tracking

()

Tracking Status
firefox39 --- disabled
firefox40 --- disabled
firefox41 --- disabled
firefox-esr31 --- disabled
firefox-esr38 --- disabled

People

(Reporter: RyanVM, Unassigned)

Details

(Keywords: intermittent-failure, leave-open, Whiteboard: [test disabled on Win8/10][stockwell disabled])

Attachments

(3 files)

https://tbpl.mozilla.org/php/getParsedLog.php?id=20071109&tree=Mozilla-Inbound

Rev3 WINNT 5.1 mozilla-inbound opt test mochitest-other on 2013-02-25 09:53:29 PST for push 77269eb211df
slave: talos-r3-xp-066

10:08:32     INFO -  4225 INFO TEST-START | chrome://mochitests/content/a11y/accessible/focus/test_focusedChild.html
10:08:32     INFO -  4226 INFO TEST-INFO | chrome://mochitests/content/a11y/accessible/focus/test_focusedChild.html | must wait for load
10:08:32     INFO -  4227 INFO TEST-INFO | chrome://mochitests/content/a11y/accessible/focus/test_focusedChild.html | Invoke the 'focusedChild for application accessible' test { scenario #0: expected 'focus' event;  }
10:13:52     INFO -  4228 ERROR TEST-UNEXPECTED-FAIL | chrome://mochitests/content/a11y/accessible/focus/test_focusedChild.html | Test timed out.
10:13:52     INFO -  args: ['C:\\talos-slave\\test\\build\\tests\\bin\\screenshot.exe', 'c:\\docume~1\\cltbld\\locals~1\\temp\\mozilla-test-fail_1jcdcv']
10:13:54     INFO -  SCREENSHOT: <see log>
10:13:54     INFO -  4229 INFO TEST-END | chrome://mochitests/content/a11y/accessible/focus/test_focusedChild.html | finished in 321776ms

The screenshot is showing an xpcshell crash dialog?
Backed out in https://hg.mozilla.org/integration/mozilla-inbound/rev/9b9fd8197987 because, unlikely as this seems, every Android build after it landed failed with a warning-as-error about an unused variable in gfx/gl/GLContextProviderEGL.cpp, while retriggers on the last green push remained green.
relanded in https://hg.mozilla.org/integration/mozilla-inbound/rev/1fc4eaf5f5a4

(the real culprit was a push that didn't show up in pushlog)
(In reply to David Baron [:dbaron] (don't cc:, use needinfo? instead) from comment #4)
> (the real culprit was a push that didn't show up in pushlog)

Filed bug 846249 for that.
The comment 7 one has a "Windows has recovered from a serious error" dialog instead.
focus event is missing when new window is open:

3:09:21     INFO -  4393 INFO TEST-INFO | chrome://mochitests/content/a11y/accessible/focus/test_focusedChild.html | must wait for load
13:09:21     INFO -  Event type: reorder. Target: ['iframe@id="testframe" node', address: [object HTMLIFrameElement], role: internal frame, address: [xpconnect wrapped nsIAccessible]]
13:09:22     INFO -  scenario #0, registered events number: 1
13:09:22     INFO -  registered: event type: focus, target: getDialogAccessible, arg: [object Object]
13:09:22     INFO -  Event queue:
13:09:22     INFO -    invoke: focusedChild for application accessible
13:09:22     INFO -  4394 INFO TEST-INFO | chrome://mochitests/content/a11y/accessible/focus/test_focusedChild.html | Invoke the 'focusedChild for application accessible' test { scenario #0: expected 'focus' event;  }
13:09:22     INFO -  Event type: reorder. Target: [' no node info ', role: app root, name: 'Nightly', address: [xpconnect wrapped nsIAccessible]]
13:09:22     INFO -  Event type: state change. Target: ['toolbarbutton@id="urlbar-reload-button" node', address: [object XULElement], role: pushbutton, name: 'Location', address: [xpconnect wrapped nsIAccessible]]
13:09:22     INFO -  Event type: state change. Target: ['toolbarbutton@id="urlbar-reload-button" node', address: [object XULElement], role: pushbutton, name: 'Location', address: [xpconnect wrapped nsIAccessible]]
13:14:46     INFO -  4395 ERROR TEST-UNEXPECTED-FAIL | chrome://mochitests/content/a11y/accessible/focus/test_focusedChild.html | Test timed out.
(In reply to alexander :surkov from comment #13)
> enable focus logging (see comment #11) -
> https://hg.mozilla.org/integration/mozilla-inbound/rev/8f91725a3005

Alexander did you look into this since the focus logging? If not maybe I can investigate...
no, I didn't. If I did then I would commented it here. Please.
alt= a dialog… it says Microsoft Windows, the system has recovered from a serious error, behind that i see a window showing the book of mozilla, and behind that the main ff window.

Bad slave?
Then again, might have been Bug 685652 as well (which landed immediately after you). I backed that out as well and we can re-land whatever was innocent.
There's no DOM focus notification so newly opened window isn't focused:

window.openDialog("about:mozilla", "AboutMozilla", "chrome,width=600,height=600")

Enn, do you have ideas how it can happen?
the problem is either on content side (comment #53) and we need somebody to look at or it is a system problem (comment #28). David, how did you get this snapshot?
Flags: needinfo?(dbolter)
(In reply to alexander :surkov from comment #153)
> the problem is either on content side (comment #53) and we need somebody to
> look at or it is a system problem (comment #28). David, how did you get this
> snapshot?

My memory is a bit fuzzy but I think the screenshot data is dumped into the log, which I cut and pasted into a file and which I saved with the right type. I probably asked Ted or someone.
Flags: needinfo?(dbolter)
(The screenshots are dumped to the log as a data URI; which can be pasted into the browser)
so if test failure is caused by the Windows steals the focus showing some dialog then perhaps nothing to do on a11y side. What is a cause of that dialog window and can we prevent it from popping up during the test run?
Or perhaps there is something the test could do instead. That explosion of failures on t-xp32-ix-004 since December was because it got a reimage that somehow left it wanting to set up a Dropbox account, but as the screenshot in https://tbpl.mozilla.org/php/getParsedLog.php?id=31799662&tree=Mozilla-Inbound#error0 shows, other suites were perfectly capable of coping with that dialog existing, and were able to get up on top of it.

You are going to be structurally prone to more trouble with crash dialogs than other suites, since if we crash in mochitest-1 then we halt running the suite and reboot the machine, but if we crash in mochitest-chrome, we halt running that suite, and start running mochitest-a11y. Dunno what you can do about that, unless the problem is that your window is large enough to wind up behind the "Windows has recovered from a serious error" dialog, and reducing the size of the window the test opens would get rid of the focus interference.
not sure I follow how the window size can help with it. If somebody steals the focus from window then can the test do anything if it was supposed to test focus receiving?
No idea, it's not my test. All I know is what's visible in the screenshots in the log, and the fact that that slave was like that for a full month, and no other tests failed on it, only this single test, despite there being a whole lot of other tests which deal with focus.
do you think that the dialog appearance might be related with test work somehow?
Assignee: nobody → yzenevich
Assignee: yzenevich → nobody
(In reply to Phil Ringnalda (:philor) from comment #163)

> but if we crash in mochitest-chrome, we halt
> running that suite, and start running mochitest-a11y.

My guess is that other focus tests lucked out; either don't follow mochitest-chrome or don't really test what we are testing. Is there a way to enforce cleanup of straggling system dialogs before running mochitest-a11y?