Closed
Bug 1295815
Opened 8 years ago
Closed 8 years ago
Intermittent dom/tests/mochitest/pointerlock/test_pointerlock-api.html | Test timed out.
Categories
(Core :: DOM: Core & HTML, defect, P3)
Core
DOM: Core & HTML
Tracking
()
RESOLVED
FIXED
mozilla55
People
(Reporter: intermittent-bug-filer, Assigned: kanru)
References
(Blocks 1 open bug)
Details
(Keywords: intermittent-failure, Whiteboard: [stockwell fixed])
Attachments
(1 file)
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment 3•8 years ago
|
||
Bulk assigning P3 to all open intermittent bugs without a priority set in Firefox components per bug 1298978.
Priority: -- → P3
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Updated•8 years ago
|
Blocks: pointer-lock
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment 15•8 years ago
|
||
All failures on windows8-64 (over half of the failures) have screenshot of the start screen... which indicates that the pointer is probably moved to a location which triggers the start screen, and thus isn't able to continue the test with the necessary mouse events.
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment 25•8 years ago
|
||
In recent failures, this seems typical:
[task 2017-03-28T16:19:55.816999Z] 16:19:55 INFO - TEST-START | dom/tests/mochitest/pointerlock/test_pointerlock-api.html
[task 2017-03-28T16:19:56.325533Z] 16:19:56 INFO - GECKO(3612) | console.error: CustomizableUI:
[task 2017-03-28T16:19:56.334209Z] 16:19:56 INFO - GECKO(3612) | Key element with id 'key_devToolboxMenuItem' for widget 'developer-button' not found!
[task 2017-03-28T16:19:56.335873Z] 16:19:56 INFO - GECKO(3612) | console.error: CustomizableUI:
[task 2017-03-28T16:19:56.337221Z] 16:19:56 INFO - GECKO(3612) | Key element with id 'key_webide' for widget 'webide-button' not found!
[task 2017-03-28T16:19:57.144158Z] 16:19:57 INFO - GECKO(3612) | [POINTERLOCK] Starting file_screenClientXYConst.html
[task 2017-03-28T16:25:23.394848Z] 16:25:23 INFO - TEST-INFO | started process screentopng
[task 2017-03-28T16:25:23.865642Z] 16:25:23 INFO - TEST-INFO | screentopng: exit 0
[task 2017-03-28T16:25:23.868493Z] 16:25:23 INFO - Buffered messages logged at 16:19:56
[task 2017-03-28T16:25:23.871715Z] 16:25:23 INFO - Testing file_screenClientXYConst.html
[task 2017-03-28T16:25:23.873583Z] 16:25:23 INFO - Buffered messages logged at 16:19:57
[task 2017-03-28T16:25:23.875536Z] 16:25:23 INFO - TEST-PASS | dom/tests/mochitest/pointerlock/test_pointerlock-api.html | A valid string reason is expected
[task 2017-03-28T16:25:23.879349Z] 16:25:23 INFO - TEST-PASS | dom/tests/mochitest/pointerlock/test_pointerlock-api.html | Reason cannot be empty
[task 2017-03-28T16:25:23.881247Z] 16:25:23 INFO - file_screenClientXYConst.html: Requesting fullscreen on parent
[task 2017-03-28T16:25:23.883017Z] 16:25:23 INFO - file_screenClientXYConst.html: Got fullscreenchange for entering
[task 2017-03-28T16:25:23.884882Z] 16:25:23 INFO - file_screenClientXYConst.html: Got mousemove via moveUnlocked
[task 2017-03-28T16:25:23.886776Z] 16:25:23 INFO - file_screenClientXYConst.html: Got pointerlockchange for entering
[task 2017-03-28T16:25:23.888586Z] 16:25:23 INFO - Buffered messages finished
Most failures are still on Windows, but some are on Linux.
There was a significant increase in failure frequency around March 26/27. https://treeherder.mozilla.org/#/jobs?repo=autoland&revision=ee52b3615da626b5968ff3df558ff0cc029f17c5 is the earliest failure around this time (there were earlier, infrequent failures on March 22 and earlier).
Comment 26•8 years ago
|
||
(In reply to Xidorn Quan [:xidorn] (UTC+10) from comment #15)
> All failures on windows8-64 (over half of the failures) have screenshot of
> the start screen... which indicates that the pointer is probably moved to a
> location which triggers the start screen, and thus isn't able to continue
> the test with the necessary mouse events.
I see that in screenshots from that time (January), but all the recent screenshots I checked are now completely black - something is different!
Updated•8 years ago
|
Whiteboard: [stockwell needswork]
Comment 27•8 years ago
|
||
https://treeherder.mozilla.org/#/jobs?repo=autoland&tochange=ee52b3615da626b5968ff3df558ff0cc029f17c5&fromchange=e8a7790bd2685ca77713d2bf8b165e7e162a443d&filter-searchStr=windows%20m-e10s(3) suggests that bug 1194751 may have caused this failure to become more frequent.
:kanru - Can you have a look?
Flags: needinfo?(kchen)
Comment 28•8 years ago
|
||
This is likely the same issue as bug 1350875 that fullscreen timing changes which makes the detection used in addFullscreenChangeContinuation no longer reliable.
But it's weird that addFullscreenChangeContinuation should generally be reliable on Windows because we dispatch the fullscreen event after the viewport size changes on Windows. So maybe viewport size change is no longer a reliable event for mouse move simulation?
Comment hidden (Intermittent Failures Robot) |
Updated•8 years ago
|
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Assignee | ||
Updated•8 years ago
|
Assignee: nobody → kchen
Flags: needinfo?(kchen)
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment 36•8 years ago
|
||
It seems all intermittents are on subtest file_screenClientXYConst.html where the synthesizeNativeMouseMove fails to generate a mousemove event. We may be able to make it more robust via repeatedly trying synthesizing mousemove until there is really one happens.
Comment 37•8 years ago
|
||
If you have idea why synthesizeNativeMouseMove may fail to trigger the mousemove event in that case, it would also be helpful. Otherwise let's just workaround it via retrying synthesizeNativeMouseMove several times with an interval.
Flags: needinfo?(kchen)
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment 40•8 years ago
|
||
this is our #2 intermittent orange, it sounds like there is progress towards a real fix here, I will wait a few days before pushing to disable this- please let me know if I can help out with things to get to a reasonable fix.
Assignee | ||
Comment 41•8 years ago
|
||
Comment hidden (mozreview-request) |
Comment hidden (Intermittent Failures Robot) |
Comment 44•8 years ago
|
||
mozreview-review |
Comment on attachment 8855883 [details]
Bug 1295815 - retry synthesizeNativeMouseMove until mousemove happens.
https://reviewboard.mozilla.org/r/127756/#review130612
::: dom/tests/mochitest/pointerlock/file_screenClientXYConst.html:107
(Diff revision 1)
> + // Bug 1295815
> + // Retrigger synthesizeNativeMouseMove until it actually happens.
> + mouseMoveIntervalID = setInterval(() => {
> - synthesizeNativeMouseMove(div, (divRect.width / 4) * 3,
> + synthesizeNativeMouseMove(div, (divRect.width / 4) * 3,
> - (divRect.height / 4) * 3);
> + (divRect.height / 4) * 3);
> + }, 10);
10ms is probably too short... I have no idea what value would be sensible, but I probably would start with something like 100ms. Hope we wouldn't end up getting too many events...
Attachment #8855883 -
Flags: review?(xidorn+moz) → review+
Comment hidden (Intermittent Failures Robot) |
Comment 46•8 years ago
|
||
I see a r+ here, can this land? I will disable this tomorrow if there are blocking reasons to not land this.
Flags: needinfo?(xidorn+moz)
Comment hidden (mozreview-request) |
Comment 49•8 years ago
|
||
Pushed by kchen@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/b24055689799
retry synthesizeNativeMouseMove until mousemove happens. r=xidorn
Updated•8 years ago
|
Whiteboard: [stockwell needswork] → [stockwell fixed]
Comment hidden (Intermittent Failures Robot) |
Comment 51•8 years ago
|
||
bugherder |
Status: NEW → RESOLVED
Closed: 8 years ago
status-firefox55:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla55
Assignee | ||
Updated•8 years ago
|
Flags: needinfo?(kchen)
Updated•8 years ago
|
status-firefox52:
--- → wontfix
status-firefox53:
--- → affected
status-firefox54:
--- → affected
status-firefox-esr52:
--- → affected
Comment 52•8 years ago
|
||
bugherder uplift |
Flags: in-testsuite+
Comment 53•8 years ago
|
||
bugherder uplift |
Comment 54•8 years ago
|
||
bugherder uplift |
Comment 55•8 years ago
|
||
bugherder uplift |
Comment hidden (Intermittent Failures Robot) |
Updated•6 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•