Closed Bug 931445 Opened 11 years ago Closed 8 years ago

Intermittent dom/tests/mochitest/pointerlock/test_pointerlock-api.html | Test timed out.

Categories

(Core :: DOM: Core & HTML, defect)

Product:
Core
Component:
DOM: Core & HTML
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla51
Tracking Flags:
Tracking Status
firefox46 --- disabled
firefox47 --- disabled
firefox48 --- disabled
firefox49 --- wontfix
firefox50 --- fixed
firefox51 --- fixed

People

(Reporter: cbook, Assigned: xidorn)

References

(Depends on 1 open bug, Blocks 1 open bug,
URL
)

Details

(Keywords: intermittent-failure, Whiteboard: [rr-chaos])

Attachments

(1 file, 4 obsolete files)

Bug 931445 part 5 - Avoid childIframe subtest to be started twice.
58 bytes, text/x-review-board-request
smaug
: review+
Details
Rev4 MacOSX Snow Leopard 10.6 profiling opt test mochitest-4 on 2013-10-25 23:21:28 PDT for push e6ce977623eb slave: talos-r4-snow-034 https://tbpl.mozilla.org/php/getParsedLog.php?id=29702435&tree=Profiling 764 ERROR TEST-UNEXPECTED-FAIL | /tests/dom/tests/mochitest/pointerlock/test_pointerlock-api.html | Test timed out. 3403 ERROR TEST-UNEXPECTED-FAIL | /tests/editor/libeditor/base/tests/test_bug586662.html | Test timed out. 3404 ERROR TEST-UNEXPECTED-FAIL | /tests/editor/libeditor/base/tests/test_bug586662.html | [SimpleTest.finish()] waitForFocus() was called a different number of times from the number of callbacks run. Maybe the test terminated prematurely -- be sure to use SimpleTest.waitForExplicitFinish(). - got 1, expected 0 3450 ERROR TEST-UNEXPECTED-FAIL | /tests/editor/libeditor/base/tests/test_bug795785.html | Test timed out. 3451 ERROR TEST-UNEXPECTED-FAIL | /tests/editor/libeditor/base/tests/test_bug795785.html | [SimpleTest.finish()] waitForFocus() was called a different number of times from the number of callbacks run. Maybe the test terminated prematurely -- be sure to use SimpleTest.waitForExplicitFinish(). - got 1, expected 0 8311 ERROR TEST-UNEXPECTED-FAIL | /tests/editor/libeditor/html/tests/test_CF_HTML_clipboard.html | Test timed out. 8312 ERROR TEST-UNEXPECTED-FAIL | (SimpleTest/TestRunner.js) | 4 test timeouts, giving up. 8313 ERROR TEST-UNEXPECTED-FAIL | (SimpleTest/TestRunner.js) | Skipping 394 remaining tests. 8314 ERROR TEST-UNEXPECTED-FAIL | (SimpleTest/TestRunner.js) | [SimpleTest.finish()] waitForFocus() was called a different number of times from the number of callbacks run. Maybe the test terminated prematurely -- be sure to use SimpleTest.waitForExplicitFinish(). - got 1, expected 0 8315 ERROR TEST-UNEXPECTED-FAIL | (SimpleTest/TestRunner.js) | /tests/editor/libeditor/html/tests/test_CF_HTML_clipboard.html finished in a non-clean fashion, probably because it didn't call SimpleTest.finish() Re
I've got the late-September Win7 spike narrowed down to this m-c range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=16ff803b47a9&tochange=43ab820c7b68 Will work on bisecting the fx-team pushes next.
Try bisection confirms that the September spike is a regression from bug 1071821. Dao, can you please take a look?
Blocks: 1071821
Flags: needinfo?(dao)
As this was flaky before bug 1071821, this is likely a badly written test rather than the fault of bug 1071821. I didn't write that test, so I'm not the best candidate to look into this. If nobody else can and if the timeout is too frequent, I'd suggest disabling the test.
Flags: needinfo?(dao)
David, any interest in taking a look at this issue or should I just disable the test on Windows?
Flags: needinfo?(david.humphrey)
I can't look into it atm, so maybe disable, yes.
Flags: needinfo?(david.humphrey)
This was disabled on Windows in bug 919106.
Whiteboard: [test disabled on Windows][leave open]
Blocks: 633602
Depends on: 1174966
Whiteboard: [test disabled on Windows][leave open]
Hmmm, appears when the tests are re-enabled. It would need some investigate, but probably not soon. If it doesn't get more serious, it wouldn't be very high-priority.
It seems this time out consists of different underlying issues: * for Windows 7, it stops at the beginning of file_retargetMouseEvents.html; * for Windows 8 and XP, it stops in file_screenClientXYConst.html after "Reason cannot be empty"; * for Linux, it seems the test gets stuck in several different positions.
It seems this intermittent is hard to reproduce. I saw only one in 300 retriggers from my try push: https://treeherder.mozilla.org/#/jobs?repo=try&revision=2dec9c12a438&selectedJob=15561172 I'm going to land a patch with some more detailed logs and hopefully we can get some helpful information from normal pushes.
Keywords: leave-open
Depends on: 1240696
It seems all timeouts are stuck on waiting for a mousemove event.
smaug, are you aware of any recent change which could make mousemove event not dispatched reliably? This issue looks weird to me, because all timeouts are stuck on waiting for mousemove event, and events should be generated from both synthesizeMouse* and synthesizeNativeMouseMove function are affected. The tests were enabled in bug 1180351, which landed on 2 Jan, however this intermittent didn't start to appear until 7 Jan. So I suppose it could be from a recent change.
Flags: needinfo?(bugs)
I'm not aware of any. Are the issues e10s only or both? Since if e10s, perhaps there has been some apz change.
Flags: needinfo?(bugs)
Both e10s and non-e10s. My understanding is that, synthesizeNativeMouseMove may not trigger the event if the target location is not caught by the window, however synthesizeMouse* should always trigger the event since it is just some hack inside the event system. Is that correct?
synthesizeNativeMouseMove should indeed dispatch the even using the OS level widget library (gtk or such) and synthesizeMouse keeps it all in Gecko level code. Both are equally hacky, just in different levels :) In e10s+synthesizeNativeMouseMove if one ends up dispatching exactly the same values twice, it is possible that we merge those events to one when crossing the parent<->child process boundary. I wonder if the mousemove is dispatched to wrong place, I mean to wrong document. Does the test run in a separate window? If not, does the even get dispatched to the parent document - the mochitest framework thing which has iframe for tests? For that case there is sendMouseEventToWindow in window utils. It sort of bypasses the hit testing for ancestor documents.
Yes, the test opens a new window for each subtest, so all subtests run in their own window. Thus I don't think the event would be dispatched to other document.
This is now our top not-yet-disabled intermittent.
I've had a patch for this which seems to be promising. I'll submit it for review soon, probably in this week...
I was able to reproduce this in rr's chaos mode, so it might be worth trying that here.
Whiteboard: [rr-chaos]
In case I forgot...
Flags: needinfo?(quanxunzhen)
(In reply to Xidorn Quan [:xidorn] (UTC+8) from comment #346) > https://treeherder.mozilla.org/#/jobs?repo=try&revision=2cfafe086b01 Hmmm, it seems this patch makes bug 1239932 much more reproducible on non-e10s, and makes two of the subtests timeout more frequently as well. But it seems to me timeout in all other subtests, as well as on Windows, has gone... Then hopefully we can debug the remaining issues more easily...
After thinking a bit more, I think my approach is wrong. The pointerlockchange event is already called asynchronously after a complete flush, so the layout should be stable enough at the point mouse event is simulated.
Flags: needinfo?(quanxunzhen)
Then I have no idea how this could be fixed. Kyle, given you've reproduced this with rr, could you help here? The basic reason is that, the handler of mousemove event is not triggered as expected, which makes the test stuck.
Flags: needinfo?(khuey)
Have you tried reproducing it in rr's chaos mode yourself. I can help out here, but you're on a different continent so if you can catch it yourself that might be more efficient ...
Flags: needinfo?(khuey) → needinfo?(quanxunzhen)
This is currently the #9 top orange overall, so any prioritization this can get would be nice (especially because we have this caught in rr?!)
It seems fixing another bug would make this intermittent much much more reliable on all platforms. Now it is easier to debug... probably.
Blocks: 1239932
Blocks: pointer-lock
FWIW, this is our #1 orange now.
Let's disable pointerlock tests on Linux... I now have no idea how to fix bug 1254448 given how GTK+ handles fullscreen......
https://hg.mozilla.org/integration/fx-team/rev/d6ee82b9a741
Flags: needinfo?(quanxunzhen)
Summary: Intermittent TEST-UNEXPECTED-FAIL | /tests/dom/tests/mochitest/pointerlock/test_pointerlock-api.html | Test timed out. → Intermittent dom/tests/mochitest/pointerlock/test_pointerlock-api.html | Test timed out.
Whiteboard: [rr-chaos] → [rr-chaos][test disabled on Linux and Windows][checkin-needed-aurora][checkin-needed-beta]
I don't think we need to disable it on Windows as it isn't that annoying as Linux...
I see enough Windows occurrences in that OrangeFactor list to think otherwise, sorry.
https://hg.mozilla.org/releases/mozilla-aurora/rev/692618630b0a
status-firefox47: --- → fixed
Whiteboard: [rr-chaos][test disabled on Linux and Windows][checkin-needed-aurora][checkin-needed-beta] → [rr-chaos][test disabled on Linux and Windows][checkin-needed-beta]
status-firefox48: --- → disabled
Whiteboard: [rr-chaos][test disabled on Linux and Windows][checkin-needed-beta] → [rr-chaos][test disabled on Linux and Windows]
Looks good enough to re-enable on Linux and probably non-e10s Windows: https://treeherder.mozilla.org/#/jobs?repo=try&revision=e41281966765 Windows with e10s may still need some investigation... (It seems the test I enabled there doesn't show up in TC tasks. Not sure what's wrong there...)
Probably not Windows for now, but Linux looks good enough...
Looks like my new patch works for e10s windows. No more "Test timed out" on this test happens again: https://treeherder.mozilla.org/#/jobs?repo=try&revision=21b8421c94e1 (The result looks awkward due to the new aws instances involved... I've checked the result of each task manually.)
Attachment #8754308 - Flags: review?(bugs) → review+
Comment on attachment 8754308 [details] MozReview Request: Bug 931445 part 1 - Remove unused code from pointerlock_utils.js. r=smaug https://reviewboard.mozilla.org/r/53368/#review50680
Attachment #8754310 - Flags: review?(bugs) → review+
Comment on attachment 8754310 [details] MozReview Request: Bug 931445 part 3 - Reset synth centering pointer when unlocking pointer. r=smaug https://reviewboard.mozilla.org/r/53894/#review50684
Comment on attachment 8754309 [details] MozReview Request: Bug 931445 part 2 - Use util code from fullscreen tests to improve robustness of pointerlock tests. r=smaug https://reviewboard.mozilla.org/r/53370/#review50690
Attachment #8754309 - Flags: review?(bugs) → review+
Assignee: nobody → bugzilla
May not be good enough for windows yet. It seems Win8 non-e10s is still failing for some different reason. There are some ideas I'd like to try, but it seems our Win8 infra has been too busy...
Let's land the existing patches without enabling on Windows first. Once our Win8 infra gets improved, I'll look into this bug again and try to enable it there.
https://hg.mozilla.org/integration/mozilla-inbound/rev/f73352ab6f99914b039485fdd9734f639fe1bbca Bug 931445 part 1 - Remove unused code from pointerlock_utils.js. r=smaug https://hg.mozilla.org/integration/mozilla-inbound/rev/0921152b9f08cc399440920af67885e9ba715892 Bug 931445 part 2 - Use util code from fullscreen tests to improve robustness of pointerlock tests. r=smaug https://hg.mozilla.org/integration/mozilla-inbound/rev/82d2c5404d8433ea7a0edde20523c2e32dcc505b Bug 931445 part 3 - Reset synth centering pointer when unlocking pointer. r=smaug
Interesting, I can stably reproduce the issue of failure on apz test with my local Linux build. I'll investigate it tomorrow.
It seems if the pointer does not fall in the area of the browser window, the APZ tests would fail. And the pointerlock test reliably throws the pointer to some place outside the window (likely at (0,0)), thus that failure.
(In reply to Xidorn Quan [:xidorn] (UTC+10) from comment #403) > This try push has some debug log for this bug, which may or may not be > useful for the APZ test issue here: > https://treeherder.mozilla.org/#/jobs?repo=try&revision=11cce6572efd > > You can also have a look at the failures on m-i: > https://treeherder.mozilla.org/#/jobs?repo=mozilla- > inbound&revision=6db35dcc68856908a0f25e3072fec2fd0cd0662c&filter- > job_group_symbol=M-e10s&filter-job_type_symbol=4 Thanks. > > > Anyway, this patch at least works around the failure. The try result in > > > comment 395 looks promising. > > > > That try run doesn't have any windows jobs, and the lack of mousemove event > > is specific to windows. > > I'm not enabling this test on Windows at this very present, so I'm not too > worried about this. (I'll need to worry about it very soon, though) helper_drag_click *is* enabled on Windows, and that's the one that I expect will fail with this patch. So it is something to worry about, regardless of what you do with the pointerlock tests. > > That being said, if you change the line you added to this: > > > > yield synthesizeNativeMouseEvent(document.getElementById('b'), 5, 5, > > nativeMouseMoveEventMsg(), driveTest); > > > > (i.e. don't wait for the mousemove event), then it should work on both Linux > > and Windows, so I'd be ok with that. > > I'll try if that works tomorrow. It's getting late here... Thanks. If you do another try push please include M-e10s-4 on windows as well, to make sure the helper_drag_click test doesn't break there.
Review commit: https://reviewboard.mozilla.org/r/55058/diff/#index_header See other reviews: https://reviewboard.mozilla.org/r/55058/
Attachment #8754308 - Attachment description: MozReview Request: Bug 931445 part 1 - Remove unused code from pointerlock_utils.js. r?smaug → MozReview Request: Bug 931445 part 1 - Remove unused code from pointerlock_utils.js. r=smaug
Attachment #8754309 - Attachment description: MozReview Request: Bug 931445 part 2 - Use util code from fullscreen tests to improve robustness of pointerlock tests. r?smaug → MozReview Request: Bug 931445 part 2 - Use util code from fullscreen tests to improve robustness of pointerlock tests. r=smaug
Attachment #8754310 - Attachment description: MozReview Request: Bug 931445 part 3 - Reset synth centering pointer when unlocking pointer. r?smaug → MozReview Request: Bug 931445 part 3 - Reset synth centering pointer when unlocking pointer. r=smaug
Attachment #8756245 - Flags: review?(bugmail.mozilla)
Comment on attachment 8754308 [details] MozReview Request: Bug 931445 part 1 - Remove unused code from pointerlock_utils.js. r=smaug Review request updated; see interdiff: https://reviewboard.mozilla.org/r/53368/diff/1-2/
Comment on attachment 8754309 [details] MozReview Request: Bug 931445 part 2 - Use util code from fullscreen tests to improve robustness of pointerlock tests. r=smaug Review request updated; see interdiff: https://reviewboard.mozilla.org/r/53370/diff/1-2/
Comment on attachment 8754310 [details] MozReview Request: Bug 931445 part 3 - Reset synth centering pointer when unlocking pointer. r=smaug Review request updated; see interdiff: https://reviewboard.mozilla.org/r/53894/diff/1-2/
Attachment #8756245 - Flags: review?(bugmail.mozilla)
Comment on attachment 8756245 [details] MozReview Request: Bug 931445 part 4 - Ensure pointer is moved into the window for APZ mouseevent test. r?kats https://reviewboard.mozilla.org/r/55058/#review51744 ::: gfx/layers/apz/test/mochitest/helper_drag_click.html:15 (Diff revision 1) > + // Ensure the pointer is properly moved before. > + yield synthesizeNativeMouseMoveAndWaitForMoveEvent(document.getElementById('b'), 5, 5, driveTest); Can you describe what problem you were seeing that requires this? I'm particularly confused because this test runs right after helper_click.html, and that would presumably suffer from the same problem - the synthesizeNativeClick function that it calls just does mousedown/mouseup without any mousemoves. I've also seen behaviour on windows where if you synthesize a mouse move to the same position that the mouse is already at, then the OS doesn't actually generate the mouse input, and so gecko never dispatches the mousemove event. In this case, the coordinates you are moving to are probably going to be the same as the coordinates the mouse is left at at the end of the helper_click.html test, so it seems likely to me that you will run into this problem and the test will just hang waiting for the move event.
The problem is, with the GTK widget, if you do not synthesize native mousemove, the pointer would never actually move. [1] I don't really understand the details about this issue, but it seems to me if the pointer were initially placed outside the window (especially at the the top-left corner), this subtest would stably timeout. Probably some extra event is generated when the system think the pointer is moved across the boundary (because mousedown is triggered when the system thinks the pointer is outside, and then the following mousemove actually moves the pointer), which breaks the generation of click event. Anyway, this patch at least works around the failure. The try result in comment 395 looks promising. [1] https://dxr.mozilla.org/mozilla-central/rev/5511d54a3f172c1d68f98cc55dce4de1d0ba1b51/widget/gtk/nsWindow.cpp#6813-6817
Flags: needinfo?(bugmail.mozilla)
(In reply to Xidorn Quan [:xidorn] (UTC+10) from comment #401) > The problem is, with the GTK widget, if you do not synthesize native > mousemove, the pointer would never actually move. [1] > > I don't really understand the details about this issue, but it seems to me > if the pointer were initially placed outside the window (especially at the > the top-left corner), this subtest would stably timeout. > > Probably some extra event is generated when the system think the pointer is > moved across the boundary (because mousedown is triggered when the system > thinks the pointer is outside, and then the following mousemove actually > moves the pointer), which breaks the generation of click event. Hm, do you have a link to a try run that actually shows this timeout? I haven't run into this issue yet and I would like to find out more. > Anyway, this patch at least works around the failure. The try result in > comment 395 looks promising. That try run doesn't have any windows jobs, and the lack of mousemove event is specific to windows. That being said, if you change the line you added to this: yield synthesizeNativeMouseEvent(document.getElementById('b'), 5, 5, nativeMouseMoveEventMsg(), driveTest); (i.e. don't wait for the mousemove event), then it should work on both Linux and Windows, so I'd be ok with that.
Flags: needinfo?(bugmail.mozilla)
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #402) > (In reply to Xidorn Quan [:xidorn] (UTC+10) from comment #401) > > The problem is, with the GTK widget, if you do not synthesize native > > mousemove, the pointer would never actually move. [1] > > > > I don't really understand the details about this issue, but it seems to me > > if the pointer were initially placed outside the window (especially at the > > the top-left corner), this subtest would stably timeout. > > > > Probably some extra event is generated when the system think the pointer is > > moved across the boundary (because mousedown is triggered when the system > > thinks the pointer is outside, and then the following mousemove actually > > moves the pointer), which breaks the generation of click event. > > Hm, do you have a link to a try run that actually shows this timeout? I > haven't run into this issue yet and I would like to find out more. This try push has some debug log for this bug, which may or may not be useful for the APZ test issue here: https://treeherder.mozilla.org/#/jobs?repo=try&revision=11cce6572efd You can also have a look at the failures on m-i: https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=6db35dcc68856908a0f25e3072fec2fd0cd0662c&filter-job_group_symbol=M-e10s&filter-job_type_symbol=4 > > Anyway, this patch at least works around the failure. The try result in > > comment 395 looks promising. > > That try run doesn't have any windows jobs, and the lack of mousemove event > is specific to windows. I'm not enabling this test on Windows at this very present, so I'm not too worried about this. (I'll need to worry about it very soon, though) > That being said, if you change the line you added to this: > > yield synthesizeNativeMouseEvent(document.getElementById('b'), 5, 5, > nativeMouseMoveEventMsg(), driveTest); > > (i.e. don't wait for the mousemove event), then it should work on both Linux > and Windows, so I'd be ok with that. I'll try if that works tomorrow. It's getting late here...
Comment on attachment 8754308 [details] MozReview Request: Bug 931445 part 1 - Remove unused code from pointerlock_utils.js. r=smaug Review request updated; see interdiff: https://reviewboard.mozilla.org/r/53368/diff/2-3/
Attachment #8756245 - Flags: review?(bugmail.mozilla)
Comment on attachment 8754309 [details] MozReview Request: Bug 931445 part 2 - Use util code from fullscreen tests to improve robustness of pointerlock tests. r=smaug Review request updated; see interdiff: https://reviewboard.mozilla.org/r/53370/diff/2-3/
Comment on attachment 8754310 [details] MozReview Request: Bug 931445 part 3 - Reset synth centering pointer when unlocking pointer. r=smaug Review request updated; see interdiff: https://reviewboard.mozilla.org/r/53894/diff/2-3/
Comment on attachment 8756245 [details] MozReview Request: Bug 931445 part 4 - Ensure pointer is moved into the window for APZ mouseevent test. r?kats Review request updated; see interdiff: https://reviewboard.mozilla.org/r/55058/diff/1-2/
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #402) > yield synthesizeNativeMouseEvent(document.getElementById('b'), 5, 5, > nativeMouseMoveEventMsg(), driveTest); > > (i.e. don't wait for the mousemove event), then it should work on both Linux > and Windows, so I'd be ok with that. The issue with this method is that, the mouse move event would be dispatched after the mouse down on Linux [1], but I guess that doesn't matter a lot here. [1] https://dxr.mozilla.org/mozilla-central/rev/d6d4e8417d2fd71fdf47c319b7a217f6ace9d5a5/widget/gtk/nsWindow.cpp#6813-6817
Attachment #8756245 - Flags: review?(bugmail.mozilla) → review+
Comment on attachment 8756245 [details] MozReview Request: Bug 931445 part 4 - Ensure pointer is moved into the window for APZ mouseevent test. r?kats https://reviewboard.mozilla.org/r/55058/#review52182 Thanks! ::: gfx/layers/apz/test/mochitest/helper_drag_click.html:15 (Diff revision 2) > <script type="application/javascript"> > > function* runTest() { > document.addEventListener('click', clicked, false); > > + // Ensure the pointer is properly moved before. Please update the comment to "Ensure the pointer is inside the window"
https://hg.mozilla.org/integration/mozilla-inbound/rev/67bf9ee1756489deb5ca3bface784702f1f52a26 Bug 931445 part 1 - Remove unused code from pointerlock_utils.js. r=smaug https://hg.mozilla.org/integration/mozilla-inbound/rev/b084784405ef73f3e895af2fdee748c2c2d51789 Bug 931445 part 2 - Use util code from fullscreen tests to improve robustness of pointerlock tests. r=smaug https://hg.mozilla.org/integration/mozilla-inbound/rev/79ba5815f9aa29772dd6bbfc8178999957c0c7ea Bug 931445 part 3 - Reset synth centering pointer when unlocking pointer. r=smaug https://hg.mozilla.org/integration/mozilla-inbound/rev/5a92875424b0e8bb9fbd0858de85ebad4852b033 Bug 931445 part 4 - Ensure pointer is moved into the window for APZ mouseevent test. r=kats
https://hg.mozilla.org/integration/mozilla-inbound/rev/5cbadad4fd9c0463697102f249e1c86ce98d01c1 Bug 931445 part 1 - Remove unused code from pointerlock_utils.js. r=smaug https://hg.mozilla.org/integration/mozilla-inbound/rev/a350fb7c1dbac7302db5b096de2cde327ba600da Bug 931445 part 2 - Use util code from fullscreen tests to improve robustness of pointerlock tests. r=smaug https://hg.mozilla.org/integration/mozilla-inbound/rev/ab3d00f4e239cc38d8c692d2854689af11537eda Bug 931445 part 3 - Reset synth centering pointer when unlocking pointer. r=smaug https://hg.mozilla.org/integration/mozilla-inbound/rev/daf83079577fa7b8407c18164c6cf490290c8304 Bug 931445 part 4 - Ensure pointer is moved into the window for APZ mouseevent test. r=kats
Whiteboard: [rr-chaos][test disabled on Linux and Windows] → [rr-chaos][test disabled on Windows]
Hmmm, new timeout in tc tests which I didn't retrigger much because I couldn't...
Flags: needinfo?(bugzilla)
Seems the majority of the new timeouts is after this line: > INFO file_retargetMouseEvents.html: Got parent DOMMouseScroll
This is a silly bug that start() is called twice in this subtest, one from the load event of the document (by pointerlock_utils.js), the other is by onload of the iframe. Given the document's load event comes later, I removed the onload of iframe. Review commit: https://reviewboard.mozilla.org/r/69126/diff/#index_header See other reviews: https://reviewboard.mozilla.org/r/69126/
Attachment #8777604 - Flags: review?(bugs)
Attachment #8754308 - Attachment is obsolete: true
Attachment #8754309 - Attachment is obsolete: true
Attachment #8754310 - Attachment is obsolete: true
Attachment #8756245 - Attachment is obsolete: true
https://treeherder.mozilla.org/#/jobs?repo=try&revision=8d370a82c392 I tend to close this bug with this patch. This silly mistake introduces a race condition in the pointerlock test, which can explain many timeouts here.
Flags: needinfo?(xidorn+moz)
Keywords: leave-open
Attachment #8777604 - Flags: review?(bugs) → review+
Comment on attachment 8777604 [details] Bug 931445 part 5 - Avoid childIframe subtest to be started twice. https://reviewboard.mozilla.org/r/69126/#review66348 yeah, that magical start() is error prone.
Keywords: checkin-needed
Pushed by cbook@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/469adeba9212 Part 5 - Avoid childIframe subtest to be started twice. r=smaug
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/469adeba9212
Status: NEW → RESOLVED
Closed: 8 years ago
status-firefox51: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla51
Blocks: 1286931
The new OS X intermittent is bug 1238838, which weirdly shows up recently.
Whiteboard: [rr-chaos][test disabled on Windows] → [rr-chaos]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: