Closed Bug 845134 Opened 11 years ago Closed 2 years ago

Intermittent focus/test_focusedChild.html | Test timed out.

Categories

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

x86
Windows XP
defect

Tracking

()

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

People

(Reporter: RyanVM, Unassigned)

Details

(Keywords: intermittent-failure, 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.
(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?
Attached image win8 screenshot
Looks like the same basic issue is still occurring judging by the screenshots. The spike today is from the GPO changes deployed in bug 1169243. Given that those changes appear to be successfully fixing an entire class of failures we were previously seeing, I think we should disable the test for now.
Flags: needinfo?(wkocher)
Maybe one of our intrepid a11y folks can reproduce locally?

Otherwise, given that this was a permafail, I'd suspect that either extra logging on Try or a loaner slave could work for hunting down whatever's at fault here.
Flags: needinfo?(dbolter)
Whiteboard: [leave open] → [test disabled on Win8][leave open]
(In reply to Wes Kocher (:KWierso) from comment #311)
> https://hg.mozilla.org/mozilla-central/rev/8be8deb10e4f

Guess we'll need this on at least aurora, too.
(In reply to Wes Kocher (:KWierso) from comment #320)
> Guess we'll need this on at least aurora, too.

Indeed, it'll need to land on all support Fx release branches. But on the bright side, we have green runs now.
Flags: needinfo?(ryanvm)
(In reply to Treeherder Robot from comment #355)
> log:
> https://treeherder.mozilla.org/logviewer.html#?repo=mozilla-
> inbound&job_id=10630023
> repository: mozilla-inbound
> start_time: 2015-06-10T16:09:17
> who: wkocher[at]mozilla[dot]com
> machine: t-xp32-ix-070
> buildname: Windows XP 32-bit mozilla-inbound debug test mochitest-other
> revision: 7c72328e341b
> 
> Return code: 1
> 170 INFO TEST-UNEXPECTED-FAIL |
> chrome://mochitests/content/a11y/accessible/tests/mochitest/focus/
> test_focusedChild.html | Test timed out. - expected PASS
> 199 INFO TEST-UNEXPECTED-ERROR |
> chrome://mochitests/content/a11y/accessible/tests/mochitest/hittest/
> test_zoom.html | called finish() multiple times
> Return code: 1
> Return code: 1


Screenshot for this one on XP:
http://mozilla-releng-blobs.s3.amazonaws.com/blobs/mozilla-inbound/sha512/55f1dca0f2fc457e93827fdf31c8b8e03b1f5253e5687f8cce032e3742a041c7b1b00d6a9f56fa9eecf0b71a747e8b35fba8f78af347e012aeb68cc667bfebdd
I backed out bug 1164443 in the hopes that it'll fix the firewall issues.
(In reply to Wes Kocher (:KWierso) from comment #365)
> I backed out bug 1164443 in the hopes that it'll fix the firewall issues.

I'm guessing it did since the frequency went down again.

So if I understand correctly we're left with a disabled test which we'll need to somehow make more resilient to system dialogs... I don't think we have anyone who can look at this soon.
Flags: needinfo?(dbolter)
(In reply to Treeherder Robot from comment #374)
> log:
> https://treeherder.mozilla.org/logviewer.html#?repo=mozilla-
> inbound&job_id=10744796
> repository: mozilla-inbound
> start_time: 2015-06-12T15:54:43
> who: wkocher[at]mozilla[dot]com
> machine: t-xp32-ix-103
> buildname: Windows XP 32-bit mozilla-inbound debug test mochitest-other
> revision: 3f6b09143c8b
> 
> Return code: 1
> 170 INFO TEST-UNEXPECTED-FAIL |
> chrome://mochitests/content/a11y/accessible/tests/mochitest/focus/
> test_focusedChild.html | Test timed out. - expected PASS
> 199 INFO TEST-UNEXPECTED-ERROR |
> chrome://mochitests/content/a11y/accessible/tests/mochitest/hittest/
> test_zoom.html | called finish() multiple times
> Return code: 1
> Return code: 1

http://mozilla-releng-blobs.s3.amazonaws.com/blobs/mozilla-inbound/sha512/7de06c4bb411163785c0a684d15fd34582eb0b6af34f0b9474940a6605a8c6cac54350e04df2b20553f84620fceabbd172e6ed1d4a05222c58679eb01666672e


That's a fun one...
os_version landed (from bug 945869) in 32, so it isn't actually disabled on esr31, where the only choices are to disable it on all Windows versions, use the heinous "version" instead (might be "6.1.7601", might not be), or write some in-test code to bail on Win8.
Bulk assigning P3 to all open intermittent bugs without a priority set in Firefox components per bug 1298978.
Priority: -- → P3
I am seeing a lot of these timeouts in my try build for a patch that I have written in bug 1379643:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=540d14474f7cb3e348ccb2070c72199bc18a7d3b&selectedJob=115031722

Do we know anything about why we are seeing these?
Flags: needinfo?(surkov.alexander)
There's no focus events in the log at all [1]. Do you observe this behavior locally?

[1] https://treeherder.mozilla.org/logviewer.html#?job_id=115031722&repo=try&lineNumber=3983-4099
Flags: needinfo?(surkov.alexander)
I have not been able to reproduce locally.
Recall that the test is currently skipped on some Windows versions:

https://dxr.mozilla.org/mozilla-central/rev/7d2e89fb92331d7e4296391213c1e63db628e046/accessible/tests/mochitest/focus/a11y.ini#6

[test_focusedChild.html]
skip-if = (os == 'win' && (os_version == '6.2' || os_version == '6.3')) # bug 845134


All current failures are Windows 10, a new-ish test platform for us. Should we skip on Windows 10 also? Or on all Windows, to avoid future pain??
Let's skip this on Windows 10 for now, unless you have a fix.
Attachment #8890012 - Flags: review?(surkov.alexander)
Summary: Intermittent content/a11y/accessible/focus/test_focusedChild.html | Test timed out. → Intermittent focus/test_focusedChild.html | Test timed out.
Keywords: leave-open
Whiteboard: [test disabled on Win8][leave open] → [test disabled on Win8][stockwell needswork]
Comment on attachment 8890012 [details] [diff] [review]
skip on windows 10

Review of attachment 8890012 [details] [diff] [review]:
-----------------------------------------------------------------

r=me
Attachment #8890012 - Flags: review?(surkov.alexander) → review+
Pushed by gbrown@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/ea5a24395bb7
Skip test_focusedChild.html on Win 10 also; r=surkov
Whiteboard: [test disabled on Win8][stockwell needswork] → [test disabled on Win8/10][stockwell disabled]
Wouldn't it be easier to just |skip-if = (os == 'win' && os_version != '6.1')| since Win7 is all that's left from that list anyway?
Good idea - will keep in mind for next time!
The test is still running, and failing, on Win 10; I'll try Ryan's suggestion...
Pushed by gbrown@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/92c853365ed5
Modify annotation to skip test_focusedChild.html on Windows 10; r=me,test-only
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.