Closed Bug 1394132 Opened 7 years ago Closed 7 years ago

Intermittent dom/tests/mochitest/pointerlock/test_pointerlock-api.html | called finish() multiple times

Categories

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

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

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla57
Tracking Flags:
Tracking Status
firefox57 --- fixed

People

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

References

Details

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

Attachments

(1 file)

Bug 1394132 - Ensure we only handle focus event once.
59 bytes, text/x-review-board-request
masayuki
: review+
Details
No longer blocks: 1324932
Whiteboard: [stockwell needswork:owner]
I did some retriggers:
https://treeherder.mozilla.org/#/jobs?repo=autoland&filter-searchStr=mochitest-e10s-3%20osx&tochange=59352665f35706de2acd1eb8ab0a4f5ca3f1872c&fromchange=72adcbfccfbe508a4c51c47551b6b6e0721d1818

and the root cause of this highly frequent intermittent is bug 1349255.

:freesamael, I see you authored the patches in bug 1349255, can you fix this issue in test_pointerlock-api.html soon or consider backing out our patch until this regression is fixed?
Blocks: 1349255
Flags: needinfo?(sawang)
Hmm, that's odd and looks like that something hit bug 1366686.
Taking investigation.
Assignee: nobody → sawang
Flags: needinfo?(sawang)
Add some log and reproduce it locally, found an interesting clue that file_targetOutOfFocus.html finishes twice.

362 INFO Testing file_targetOutOfFocus.html
GECKO(87339) | [POINTERLOCK] Starting file_targetOutOfFocus.html
363 INFO TEST-PASS | dom/tests/mochitest/pointerlock/test_pointerlock-api.html | file_targetOutOfFocus.html: Pointer should be locked even if the element being locked is not focused
GECKO(87339) | [POINTERLOCK] Finishing file_targetOutOfFocus.html
365 INFO must wait for focus
366 INFO TEST-PASS | dom/tests/mochitest/pointerlock/test_pointerlock-api.html | file_targetOutOfFocus.html: Pointer should be locked even if the element being locked is not focused
GECKO(87339) | [POINTERLOCK] Finishing file_targetOutOfFocus.html
I think it's related to how exitFullscreen() behaves on macOS. 
By adding logs on all event handlers in file_targetOutOfFocus.html, I found the following event sequences occured:

===== Before bug 1349255 =====
166 INFO file_targetOutOfFocus: enter
167 INFO file_targetOutOfFocus: focus
168 INFO file_targetOutOfFocus: pointerlockchange
169 INFO file_targetOutOfFocus: focus               <---
170 INFO file_targetOutOfFocus: exit

===== After bug 1349255 ======
166 INFO file_targetOutOfFocus: enter
167 INFO file_targetOutOfFocus: focus
168 INFO file_targetOutOfFocus: pointerlockchange
169 INFO file_targetOutOfFocus: focus               <---
170 INFO file_targetOutOfFocus: pointerlockchange
171 INFO file_targetOutOfFocus: exit
175 INFO file_targetOutOfFocus: exit

The interesting part here is that on macOS, there's another focus event caused by exitFullscreen(), 
which doesn't happen on Linux. Focus log gave me this (between pointerlockchange & focus):
https://pastebin.mozilla.org/9030915

In comparison, on Linux it's as simple as:

file_targetOutOfFocus.html: file_targetOutOfFocus:pointerlockchange
GECKO(23866) | [Main Thread]: D/Focus <<SetFocus begin>>
GECKO(23866) | [Main Thread]: D/Focus <<SetFocus end>>
file_targetOutOfFocus.html: file_targetOutOfFocus: exit

My suggestion is to simply unregister the focus event listener after getting the 1st focus event.
However I don't really understand why on macOS exitFullscreen would generate another focus event.

Masayuki, are you OK with this fix?
Comment on attachment 8902180 [details]
Bug 1394132 - Ensure we only handle focus event once.

https://reviewboard.mozilla.org/r/173656/#review178978

::: dom/tests/mochitest/pointerlock/file_targetOutOfFocus.html:44
(Diff revision 1)
> -        input.addEventListener("focus", function() {
> +        input.addEventListener("focus", function focusHandler() {
> +          input.removeEventListener("focus", focusHandler);
>            div.requestPointerLock();
>          });

I'm not familiar with this test, but it'd be possible.

Could you use |{ once: true }| for the third argument of addEventListener rather than using removeEventListener?
https://developer.mozilla.org/en-US/docs/Web/API/EventTarget/addEventListener
Sorry thought it's reviewed.
Keywords: checkin-needed
See Also: → 1394232
Hi Masayuki, is there any other concern or anything you need from me to review the patch?
Flags: needinfo?(masayuki)
Nothing else.
Flags: needinfo?(masayuki)
Comment on attachment 8902180 [details]
Bug 1394132 - Ensure we only handle focus event once.

https://reviewboard.mozilla.org/r/173656/#review179358
Attachment #8902180 - Flags: review?(masayuki) → review+
Pushed by ryanvm@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/c4c9520160ba
Ensure we only handle focus event once. r=masayuki
Keywords: checkin-needed
Pushed by kwierso@gmail.com:
https://hg.mozilla.org/mozilla-central/rev/4722bf29a176
Ensure we only handle focus event once. r=masayuki
https://hg.mozilla.org/mozilla-central/rev/4722bf29a176
Status: NEW → RESOLVED
Closed: 7 years ago
status-firefox57: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla57
Whiteboard: [stockwell needswork:owner] → [stockwell fixed:logic]
This doesn't seem to be fixed... :/
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Oh wait it drops after 8/31. Thought robot would only post after last update.
Status: REOPENED → RESOLVED
Closed: 7 years ago → 7 years ago
Resolution: --- → FIXED
this is the fun part of robots that scan on a weekly cadence- luckily this only happens a few times and we catch it pretty quickly.
Whiteboard: [stockwell needswork:owner] → [stockwell fixed:product]
Depends on: 1396876
No longer depends on: 1396876
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: