Closed Bug 1357082 Opened 8 years ago Closed 1 year ago

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

Categories

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

Product:
Core
Component:
DOM: Core & HTML
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1833142
Tracking Flags:
Tracking Status
firefox58 --- disabled

People

(Reporter: aryx, Assigned: smaug)

References

(Blocks 1 open bug)

Details

(Keywords: intermittent-failure, Whiteboard: [stockwell disabled])

Attachments

(3 files)

Bug 1357082 - Retry synthesizeMouseAtCenter until it is performed.
(deleted), text/x-review-board-request
xidorn
: review+
Details
patch.diff
(deleted), patch
Details | Diff | Splinter Review
Bug 1357082, try to stabilize test_pointerlock-api.html by waiting for a refreshtick before and after a sub-test run
(deleted), text/x-phabricator-request
Details
+++ This bug was initially created as a clone of Bug #1295815 +++ https://treeherder.mozilla.org/logviewer.html#?job_id=92031827&repo=autoland 07:33:58 INFO - 4203 INFO Testing file_retargetMouseEvents.html 07:33:58 INFO - Buffered messages logged at 07:28:48 07:33:58 INFO - 4204 INFO file_retargetMouseEvents.html: Requesting fullscreen on parent 07:33:58 INFO - 4205 INFO file_retargetMouseEvents.html: Got fullscreenchange for entering 07:33:58 INFO - 4206 INFO file_retargetMouseEvents.html: Got pointerlockchange for entering 07:33:58 INFO - Buffered messages finished 07:33:58 ERROR - 4207 INFO TEST-UNEXPECTED-FAIL | dom/tests/mochitest/pointerlock/test_pointerlock-api.html | Test timed out. 07:33:58 INFO - reportError@SimpleTest/TestRunner.js:121:7 07:33:58 INFO - TestRunner._checkForHangs@SimpleTest/TestRunner.js:142:7 07:33:58 INFO - setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5 07:33:58 INFO - setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5 07:33:58 INFO - setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5 07:33:58 INFO - setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5 07:33:58 INFO - setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5 07:33:58 INFO - setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5 07:33:58 INFO - setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5 07:33:58 INFO - setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5 07:33:58 INFO - setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5 07:33:58 INFO - setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5 07:33:58 INFO - setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5 07:33:58 INFO - TestRunner.runTests@SimpleTest/TestRunner.js:380:5 07:33:58 INFO - RunSet.runtests@SimpleTest/setup.js:194:3 07:33:58 INFO - RunSet.runall@SimpleTest/setup.js:173:5 07:33:58 INFO - hookupTests@SimpleTest/setup.js:266:5 07:33:58 INFO - EventHandlerNonNull*getTestManifest@http://mochi.test:8888/manifestLibrary.js:45:3 07:33:58 INFO - hookup@SimpleTest/setup.js:246:5 07:33:58 INFO - EventHandlerNonNull*@http://mochi.test:8888/tests?autorun=1&closeWhenDone=1&consoleLevel=INFO&manifestFile=tests.json&dumpOutputDirectory=c%3A%5Cusers%5Cgenericworker%5Cappdata%5Clocal%5Ctemp&cleanupCrashes=true:11:1
trying to run this on ubuntu 16.04, we see a much higher failure rate on linux64-opt (6 failures out of 40 runs): https://treeherder.mozilla.org/#/jobs?repo=try&revision=8d191df67e0a14bbde01312a28d827587fa9e8fb&selectedJob=103235934&filter-searchStr=linux%20mochitest-e10s-6 here is a log: https://public-artifacts.taskcluster.net/GsX2gP7CTDGZH4e13Yvfpg/0/public/logs/live_backing.log and we see this failure: [task 2017-05-31T02:37:16.329086Z] 02:37:16 INFO - TEST-PASS | dom/tests/mochitest/pointerlock/test_pointerlock-api.html | file_removedFromDOM.html: Root element should have entered fullscreen [task 2017-05-31T02:37:16.331060Z] 02:37:16 INFO - Buffered messages logged at 02:32:05 [task 2017-05-31T02:37:16.333006Z] 02:37:16 INFO - TEST-PASS | dom/tests/mochitest/pointerlock/test_pointerlock-api.html | file_removedFromDOM.html: #div should have locked the pointer [task 2017-05-31T02:37:16.334930Z] 02:37:16 INFO - TEST-PASS | dom/tests/mochitest/pointerlock/test_pointerlock-api.html | file_removedFromDOM.html: Pointer should have been unlocked [task 2017-05-31T02:37:16.336766Z] 02:37:16 INFO - TEST-PASS | dom/tests/mochitest/pointerlock/test_pointerlock-api.html | file_removedFromDOM.html: #inner should have locked the pointer [task 2017-05-31T02:37:16.338708Z] 02:37:16 INFO - TEST-PASS | dom/tests/mochitest/pointerlock/test_pointerlock-api.html | file_removedFromDOM.html: Pointer should have been unlocked [task 2017-05-31T02:37:16.340456Z] 02:37:16 INFO - must wait for focus [task 2017-05-31T02:37:16.342130Z] 02:37:16 INFO - Testing file_retargetMouseEvents.html [task 2017-05-31T02:37:16.343814Z] 02:37:16 INFO - Buffered messages logged at 02:32:06 [task 2017-05-31T02:37:16.345520Z] 02:37:16 INFO - file_retargetMouseEvents.html: Requesting fullscreen on parent [task 2017-05-31T02:37:16.347336Z] 02:37:16 INFO - file_retargetMouseEvents.html: Got fullscreenchange for entering [task 2017-05-31T02:37:16.349102Z] 02:37:16 INFO - file_retargetMouseEvents.html: Got pointerlockchange for entering [task 2017-05-31T02:37:16.351096Z] 02:37:16 INFO - Buffered messages finished [task 2017-05-31T02:37:16.353012Z] 02:37:16 INFO - TEST-UNEXPECTED-FAIL | dom/tests/mochitest/pointerlock/test_pointerlock-api.html | Test timed out. [task 2017-05-31T02:37:16.354714Z] 02:37:16 INFO - reportError@SimpleTest/TestRunner.js:121:7 [task 2017-05-31T02:37:16.356367Z] 02:37:16 INFO - TestRunner._checkForHangs@SimpleTest/TestRunner.js:142:7 [task 2017-05-31T02:37:16.358022Z] 02:37:16 INFO - setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5 [task 2017-05-31T02:37:16.359736Z] 02:37:16 INFO - setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5 [task 2017-05-31T02:37:16.361424Z] 02:37:16 INFO - setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5 [task 2017-05-31T02:37:16.363092Z] 02:37:16 INFO - setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5 [task 2017-05-31T02:37:16.364829Z] 02:37:16 INFO - setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5 [task 2017-05-31T02:37:16.366462Z] 02:37:16 INFO - setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5 [task 2017-05-31T02:37:16.368186Z] 02:37:16 INFO - setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5 [task 2017-05-31T02:37:16.369880Z] 02:37:16 INFO - setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5 [task 2017-05-31T02:37:16.371904Z] 02:37:16 INFO - setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5 [task 2017-05-31T02:37:16.373638Z] 02:37:16 INFO - setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5 [task 2017-05-31T02:37:16.375360Z] 02:37:16 INFO - setTimeout handler*TestRunner._checkForHangs@SimpleTest/TestRunner.js:163:5 [task 2017-05-31T02:37:16.377004Z] 02:37:16 INFO - TestRunner.runTests@SimpleTest/TestRunner.js:380:5 [task 2017-05-31T02:37:16.378594Z] 02:37:16 INFO - RunSet.runtests@SimpleTest/setup.js:194:3 [task 2017-05-31T02:37:16.380365Z] 02:37:16 INFO - RunSet.runall@SimpleTest/setup.js:173:5 [task 2017-05-31T02:37:16.382021Z] 02:37:16 INFO - hookupTests@SimpleTest/setup.js:266:5 [task 2017-05-31T02:37:16.383703Z] 02:37:16 INFO - EventHandlerNonNull*getTestManifest@http://mochi.test:8888/manifestLibrary.js:45:3 [task 2017-05-31T02:37:16.385474Z] 02:37:16 INFO - hookup@SimpleTest/setup.js:246:5 [task 2017-05-31T02:37:16.387266Z] 02:37:16 INFO - EventHandlerNonNull*@http://mochi.test:8888/tests?autorun=1&closeWhenDone=1&consoleLevel=INFO&manifestFile=tests.json&dumpOutputDirectory=%2Ftmp&cleanupCrashes=true:11:1 [task 2017-05-31T02:37:16.678319Z] 02:37:16 INFO - GECKO(3923) | MEMORY STAT | vsize 1737MB | residentFast 100MB | heapAllocated 19MB [task 2017-05-31T02:37:16.695125Z] 02:37:16 INFO - TEST-OK | dom/tests/mochitest/pointerlock/test_pointerlock-api.html | took 328010ms [task 2017-05-31T02:37:19.707650Z] 02:37:19 INFO - Error: Unable to restore focus, expect failures and timeouts. I see we hit this info message: https://dxr.mozilla.org/mozilla-central/source/dom/tests/mochitest/pointerlock/file_retargetMouseEvents.html?q=path%3Afile_retargetMouseEvents.html&redirect_type=single#185 but don't seem to get past there, maybe synthesizeMouseAtCenter() is failing for us? or we are dropping messages somehow.
I think you are right Joel. I added a retry to that function call and there are no more errors now, [1]. The only reason I can see for why this works is because it's taking a bit longer for the full screen to load on ubuntu 16.04. [1]: https://treeherder.mozilla.org/#/jobs?repo=try&revision=1e37542c61997fb827b058cb17c4185bb4487514
:gmierz, this is great, can you ask :xidorn to review the patch when ready?
:xidorn, there is a try push in comment 9 that uses this patch.
:xidorn, there is another part of the test that is failing now. I'll look through all of the tests this single test is going through, change them, then put up a new patch for review. So you can give this one an r-.
I found something interesting in the synthesizeMouse functions: https://dxr.mozilla.org/mozilla-central/source/services/sync/tps/extensions/mozmill/resource/stdlib/EventUtils.js#692 Apparently it isn't finished being implemented so it doesn't check to see if it's in the chrome process before continuing.
Ok, I think I've fixed it through this test run: https://treeherder.mozilla.org/#/jobs?repo=try&revision=6d267795b977cffe1af341d736ee0d2f2a2bbd11 I'll have a patch up for review tomorrow if all goes well.
Comment on attachment 8874913 [details] Bug 1357082 - Retry synthesizeMouseAtCenter until it is performed. Cancel r? given comment 13.
Attachment #8874913 - Flags: review?(xidorn+moz)
:xidorn, comment 16 has a test run for this patch.
Comment on attachment 8874913 [details] Bug 1357082 - Retry synthesizeMouseAtCenter until it is performed. https://reviewboard.mozilla.org/r/146286/#review151058 Sad... but, okay...
Attachment #8874913 - Flags: review?(xidorn+moz) → review+
Pushed by jmaher@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/f8d48ac82e7b Retry synthesizeMouseAtCenter until it is performed. r=xidorn
https://hg.mozilla.org/mozilla-central/rev/f8d48ac82e7b
Status: NEW → RESOLVED
Closed: 7 years ago
status-firefox55: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla55
Greg, please check if this issue is really fixed (likely too early to say if the frequency decreased). It hit again in: https://treeherder.mozilla.org/logviewer.html#?job_id=106123604&repo=mozilla-inbound
Flags: needinfo?(gmierz2)
Thanks for letting me know :aryx. It seems like this patch only reduced the frequency of occurrence on Ubuntu 16.04, and it didn't actually fix it for 12.04. I'll look into this some more this week. I think the problem might be related to bug 1352709 which seems to have found that there is an error in the event ordering from time to time.
Status: RESOLVED → REOPENED
Flags: needinfo?(gmierz2)
Resolution: FIXED → ---
I wonder if there is a patch that landed and fixed this issue because orangefactor doesn't show any problems after June 29 and based on past history, we should've had at least one failure.
Priority: P3 → P5
Hi Greg, This intermittent failure started appearing recently and the failure rate rose in the last week. Would you mind taking a look at this? Thank you.
Flags: needinfo?(gmierz2)
Hi :hsinyi, sure thing! I'm going to leave the ni? open to save this in my BMO dashboard.
There seems to have been a rise in failures on windows and based on the screenshots, they all have a windows specific menu that is open and asking us how we want to open a file (I don't know what that file is, but it is a .txt file). They also all fail on 'file_screenClientXYConst.html' [1]. I was able to test this locally and managed to get that exact same failure when I opened a windows specific menu while I didn't have focus on the browser. I "returned" focus to the browser right after and my mouse cursor was stuck in the center of the screen the entire time until the test timed out (while I had the windows menu open). Joel, would you know if there are any other bugs for an error like this? The failures on linux are mainly coming from 'file_pointerlock-api.html' [2]. It's broken for the same reason as the previous patch and I still haven't found anything for that error other than retrying the mouse move again. [1]: https://dxr.mozilla.org/mozilla-central/source/dom/tests/mochitest/pointerlock/file_screenClientXYConst.html [2]: https://dxr.mozilla.org/mozilla-central/source/dom/tests/mochitest/pointerlock/file_pointerlock-api.html
Flags: needinfo?(jmaher)
this looks like bug 1373551 which would make up 50% of the failures we are seeing.
Flags: needinfo?(jmaher)
Great, thanks! So, I'll ignore those and focus on the linux errors which I'm thinking of trying to fix with the use of 'synthesizeAndWaitNativeMouseMove(...)' if I can.
I've gone through this last batch of failures that were associated with this bug and the windows failures are still being caused by random windows specific menus being open. I've found three different types: 1) Opening an unknown txt file, 2) an opened network pane, and 3) an opened start menu (windows 8). The linux errors are still coming from the same file [1], and they are either caused by 'opener' being overwritten, or something else entirely. [1]: https://dxr.mozilla.org/mozilla-central/source/dom/tests/mochitest/pointerlock/file_pointerlock-api.html
After a bit of messing around, I think that the opener.info being undefined is a side effect of the actual problem. But the logs seem to indicate that it is the only problem. And based on the ordering of the logs it also looks like the opener.info problem happens after the hang. Here is the log I am using or debugging (from mochitest-e10s-6): https://treeherder.mozilla.org/#/jobs?repo=try&revision=c9ccfcfed748419d4191682233d087ee602acb3d&selectedJob=127200586 Now, I am wondering if anyone would know why or how opener.info becomes(or could become) undefined? Joel, would you have any ideas or know of someone that I could ask?
Flags: needinfo?(jmaher)
:xidorn, I see you have modified this test a few times, is this something you could help :gmierz solve this problem?
Flags: needinfo?(jmaher) → needinfo?(xidorn+moz)
It seems to me the issue in file_pointerlock-api.html can probably be worked around with the same approach you used in file_infiniteMovement.html and file_retargetMouseEvents.html. I have no idea why opener.info becomes undefined, but since that happens in error handler, I guess that isn't the main problem here.
Flags: needinfo?(xidorn+moz)
Thanks for the comment :xidorn. That's what I was originally thinking as well, and that's what I'm going to do now. I was hoping to be able to find the problem that causes us to need this workaround and fix that, but I haven't had any luck with that. Out of curiosity, have you been able to find out why that work around works? I'm assuming it's because synthesizing a mouse event is too fast but you may have a better answer.
Flags: needinfo?(xidorn+moz)
Attached patch patch.diff (deleted) — — Splinter Review
:xidorn, here's the patch with the work around. You can see how it ran on this try push: https://treeherder.mozilla.org/#/jobs?repo=try&revision=cd061426840a99e9e88bdb6d47ff4c98af13d6ff The test runs in mochitest-e10s-6 and it has not failed once since I've made the changes.
Assignee: nobody → gmierz2
Attachment #8906363 - Flags: review?(xidorn+moz)
Comment on attachment 8906363 [details] [diff] [review] patch.diff Review of attachment 8906363 [details] [diff] [review]: ----------------------------------------------------------------- ::: dom/tests/mochitest/pointerlock/file_pointerlock-api.html @@ +61,5 @@ > } > > document.addEventListener("pointerlockchange", function (e) { > pointerLockChangeEventFired = true; > + clearInterval(mouseMoveIntervalID); Shouldn't you clear the interval in listener of mousemove? @@ +79,5 @@ > + synthesizeMouse(document.body, 4, 4, > + { type: "contextmenu", button: 2 }, > + window); > + }, 100); > + clearInterval(mouseMoveIntervalID); Why do you clear this interval immediately after setting it? It doesn't seem to make any sense.
Attachment #8906363 - Flags: review?(xidorn+moz)
I have no idea why. I'm actually a bit concerned that doing this workaround may hurt what the test actually intends to check in some cases. And yeah, I agree that we should probably try investigating the root cause and fix that, rather than adding more workaround like this. I don't have Linux machine. If you can reproduce this issue locally, could you try adding some logs in various places through the event dispatching code path, and see where does it get blocked when this happens?
Flags: needinfo?(xidorn+moz)
I have a linux machine that I could use, but I've never managed to reproduce the problem locally. However, 1 out of 100 test runs on try in mochitest-e10s-6 almost always has the error in it so we can get some event logging through there. I'd be happy to add some logging to there although I've never touched/seen the event dispatching code. Would you be able to point me to where it starts? Or would you have some documentation I could read about that dispatching path? Please and thank you! :)
Flags: needinfo?(xidorn+moz)
I'm not familiar with event dispatching code either. If I were you, I would probably start from the C++ code entry nsDOMWindowUtils::SendMouseEvent [1] which is invoked from mouse synthesizeMouseAtPoint [2]. [1] https://searchfox.org/mozilla-central/rev/51eae084534f522a502e4b808484cde8591cb502/dom/base/nsDOMWindowUtils.cpp#676 [2] https://searchfox.org/mozilla-central/rev/51eae084534f522a502e4b808484cde8591cb502/testing/mochitest/tests/SimpleTest/EventUtils.js#414
Flags: needinfo?(xidorn+moz)
Thanks for the locations :xidorn, I'm working on getting the logs right now. I've been having some trouble getting output from the code though. I've tried using NS_WARNING, printf, & fprintf to stderr. This test isn't run on debug in mochitest-e10s-6, so I'll test it out on the debug version to see if that helps. In any case, are they any logging functions that you suggest I should use in this event-dispatching code?
Nevermind, I managed to get some output on the debug version.
I have some logs now: https://public-artifacts.taskcluster.net/UJBox7nCTYWGurO2ZLD2zw/0/public/logs/live_backing.log They aren't too helpful yet, but they seem to show that we are not getting stuck within the SendMouse* functions that I've added logging to. I'm going to look into the variables in those functions some more now to see how they change in a good run vs. a bad run.
It seems if we delay the mousemove to a runnable after the next animation frame, the frequency of this would be reduced: https://treeherder.mozilla.org/#/jobs?repo=try&revision=003bc6eb775c753bc056b82a8af38fe19d4640e9 although it still isn't fully fixed, but maybe we can land it as a mitigation.
Pushed by xquan@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/f67f8342b981 Wait until after the next animation frame to trigger mousemove.
Thanks for the patch :xidorn! It's a good mitigation for the time being. I'm pretty busy with school at the moment but I should have some more time to look at this soon (in the next few weeks) to find a complete fix.
unfortunately this fix doesn't seem to do the trick :xidorn- there is a chance it has reduced the frequency, but if any it is only slightly. :xidorn, can you take a look at this again?
Flags: needinfo?(xidorn+moz)
If that doesn't make anything better, we should probably back it out. Actually it looks like things get even worse... I don't have further idea on why this happens :/
Flags: needinfo?(xidorn+moz)
:aryx can you help backout rev: f67f8342b981
Flags: needinfo?(aryx.bugmail)
Pushed by jmaher@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/639761303cb3 Disable dom/tests/mochitest/pointerlock/test_pointerlock-api.html on linux and windows for frequent failures. r=me, a=testonly
I disabled this for frequent failures- please remember to enable this when working on a fix
Whiteboard: [stockwell disable-recommended] → [stockwell disabled]
status-firefox55: fixed → ---
status-firefox58: --- → disabled
Target Milestone: mozilla55 → ---
Something is wrong with the patch that disables this test, comment 81 is a legitimate failure. I'm guessing it misses the 'linux64-nightly' OS.
Comment 81 is on mozilla-release; the patch to disable was only landed on central for firefox 58.
Oh ok, thanks for the clarification :gbrown
I've tried something like what :xidorn has done but with one extra requestAnimationFrame() call surrounding the other: https://treeherder.mozilla.org/#/jobs?repo=try&revision=7484ea67e6d24765983b2fdd09533e751d31210f It didn't help with the problem unfortunately, and I was trying this based on what I found here: https://dxr.mozilla.org/mozilla-central/source/browser/base/content/browser-fullScreenAndPointerLock.js#172
I added some different debugging to the test which causes it to fail just before it attempts to retry the synthesizeMouse calls and I managed to get a screenshot that was not just black: https://treeherder.mozilla.org/#/jobs?repo=try&revision=9881a7c712e835042eef93fb9add3ebf9ec19a9f&selectedJob=153660621 Although it's not very helpful, I think that it does show us that the black we see could be the problem we are trying fix. Unless the black screenshot is a known issue that has nothing to do with this. If that is the case, I'm wondering if there are some events the mouse move should be waiting for, or if it's missing them even though it should be catching them. Maybe the end of the black screen fires a unique event we could use? Full screen change events could be something to look at. I ran the failing tests on a one-click loaner and the screen either fully or almost fully gets covered in a black screen and it felt to me like the time that it is black varies from one run to the next. Now, I'm thinking that the reason the 'retry until it's performed' hack works is because the black screen had plenty of time to disappear and return to the browser.
I'm going to check to see if there are any problems in this function which determines when we have finished a full screen or entered one (it's supposed to wait until the fullscreen change is finished) : https://dxr.mozilla.org/mozilla-central/source/dom/tests/mochitest/pointerlock/pointerlock_utils.js#76
The black screen sounds like the fullscreen transition, in which we cover the screen with a black window before resizing it. But the fullscreen transition is disabled on Linux by default, and this specific test should have disabled that anyway: https://searchfox.org/mozilla-central/rev/25ff55f8209d77457af99a14269c40e2f54c1fee/dom/tests/mochitest/pointerlock/test_pointerlock-api.html#35
Ah, thanks for mentioning this and pointing to the area which does this. It's very interesting that we still see the black screen in the one-click loaner runs. I'll check if the black screen we see there also occurs on a local run on a linux machine in case what we see on the loaner is only from lag. Do you have any thoughts about other next possible steps :xidorn?
(In reply to Greg Mierzwinski [:sparky] from comment #86) > I added some different debugging to the test which causes it to fail just > before it attempts to retry the synthesizeMouse calls and I managed to get a > screenshot that was not just black: > https://treeherder.mozilla.org/#/ > jobs?repo=try&revision=9881a7c712e835042eef93fb9add3ebf9ec19a9f&selectedJob=1 > 53660621 Aren't all the failures in this try push from the error "TypeError: tmp1 is undefined at mouseMoveIntervalID"? That seems to be a problem in the debugging code you add, rather than an issue of the original test.
(In reply to Greg Mierzwinski [:sparky] from comment #86) > Although it's not very helpful, I think that it does show us that the black > we see could be the problem we are trying fix. Unless the black screenshot > is a known issue that has nothing to do with this. > > If that is the case, I'm wondering if there are some events the mouse move > should be waiting for, or if it's missing them even though it should be > catching them. Maybe the end of the black screen fires a unique event we > could use? Full screen change events could be something to look at. > > I ran the failing tests on a one-click loaner and the screen either fully or > almost fully gets covered in a black screen and it felt to me like the time > that it is black varies from one run to the next. Now, I'm thinking that the > reason the 'retry until it's performed' hack works is because the black > screen had plenty of time to disappear and return to the browser. Could you point to me how can I run failing test on a one-click loaner? I can probably have a look and see if there would be something helpful.
(In reply to Xidorn Quan [:xidorn] UTC+10 from comment #90) > (In reply to Greg Mierzwinski [:sparky] from comment #86) > > I added some different debugging to the test which causes it to fail just > > before it attempts to retry the synthesizeMouse calls and I managed to get a > > screenshot that was not just black: > > https://treeherder.mozilla.org/#/ > > jobs?repo=try&revision=9881a7c712e835042eef93fb9add3ebf9ec19a9f&selectedJob=1 > > 53660621 > > Aren't all the failures in this try push from the error "TypeError: tmp1 is > undefined at mouseMoveIntervalID"? That seems to be a problem in the > debugging code you add, rather than an issue of the original test. I purposefully made the error to get a screenshot the second time synthesizeMouse was triggered to look for any differences. Instead of timing out, it just hits the tmp1 error if it needs to be called more than once. That would be great if you could. Here's a link to a recent push where the only changes made are to enable the test: https://treeherder.mozilla.org/#/jobs?repo=try&revision=d2ea3d06d93b254321d7040ad0576b292e4628ab&filter-tier=1&filter-tier=2&filter-tier=3&selectedJob=153633625 If you look at the black bar that pops up when you click an intermittent, you'll see three dots in a row horizontally. You can click that to find the one-click loaner option. Click "Create Task" at the bottom of this page and then you'll either have to wait for a loaner to become available or you'll have it right off. There's other ways also: https://developer.mozilla.org/en-US/docs/Mozilla/QA/Running_automated_tests/TaskCluster_interactive_session
And if you were wondering, to get setup in the loaner, I usually open a shell first and use option (2) to have mach available. (I also forgot to mention the dots are on the left).
I managed to reproduce the bug from time to time in a loaner by only using the following changes in pointerlock_utils.js with the 350 changed to 1000: https://hg.mozilla.org/try/diff/280002ca36dd/dom/tests/mochitest/pointerlock/pointerlock_utils.js
Priority: -- → P5
Flags: needinfo?(gmierz2)
Component: DOM → DOM: Core & HTML
Blocks: 1612553
Assignee: gmierz2 → nobody
No longer blocks: 1612553

Looks like there are multiple different errors.
Trying to stabilize the test a bit since bug 1755006 makes it fail even more often.

Assignee: nobody → bugs
Blocks: 1755006
Attachment #9267486 - Attachment description: WIP: Bug 1357082, try to stabilize test_pointerlock-api.html by waiting for a refreshtick before and after a sub-test run → Bug 1357082, try to stabilize test_pointerlock-api.html by waiting for a refreshtick before and after a sub-test run
Pushed by opettay@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/31507af11955 try to stabilize test_pointerlock-api.html by waiting for a refreshtick before and after a sub-test run r=emilio

We enabled most of the tests on all platforms in bug 1668964 and bug 1612553 for > 2 years.

We now have another single tracking issue bug 1833142. Close as dup.

Status: REOPENED → RESOLVED
Closed: 7 years ago → 1 year ago
Duplicate of bug: 1833142
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: