Closed Bug 1394132 Opened 8 years ago Closed 8 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: 8 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: 8 years ago → 8 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: