Closed Bug 1295815 Opened 8 years ago Closed 7 years ago

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

Categories

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

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

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla55
Tracking Flags:
Tracking Status
firefox52 --- wontfix
firefox-esr52 --- fixed
firefox53 --- fixed
firefox54 --- fixed
firefox55 --- fixed

People

(Reporter: intermittent-bug-filer, Assigned: kanru)

References

(Blocks 1 open bug)

Details

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

Attachments

(1 file)

Bug 1295815 - retry synthesizeNativeMouseMove until mousemove happens.
59 bytes, text/x-review-board-request
xidorn
: review+
Details 
Bulk assigning P3 to all open intermittent bugs without a priority set in Firefox components per bug 1298978.
Priority: -- → P3
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.
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).
(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!
Whiteboard: [stockwell needswork]
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?
See Also: → 1350875
Assignee: nobody → kchen
Flags: needinfo?(kchen)
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.
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)
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.
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+
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)
Yeah, I guess we can just land this...
Flags: needinfo?(xidorn+moz)
Pushed by kchen@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/b24055689799
retry synthesizeNativeMouseMove until mousemove happens. r=xidorn
Whiteboard: [stockwell needswork] → [stockwell fixed]
https://hg.mozilla.org/mozilla-central/rev/b24055689799
Status: NEW → RESOLVED
Closed: 7 years ago
status-firefox55: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla55
Flags: needinfo?(kchen)
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: