Closed Bug 745047 Opened 13 years ago Closed 12 years ago

Intermittent test_pointerlock-api.html | file_movementXY.html: mozMovementX should be equal to eNow.screenX-ePrevious.screenX - got 10, expected 6 or got 14, expected 10

Categories

(Core :: DOM: Events, defect)

Product:
Core
Component:
DOM: Events
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: philor, Assigned: cpearce)

References

(Depends on 1 open bug)

Details

(Keywords: intermittent-failure, Whiteboard: [fixed by workaround for now])

Attachments

(1 file)

Patch: work around the real problem
(deleted), patch
smaug
: review+
Details | Diff | Splinter Review
https://tbpl.mozilla.org/php/getParsedLog.php?id=10856152&tree=Profiling Rev3 Fedora 12x64 profiling opt test mochitests-3/5 on 2012-04-12 17:07:35 PDT for push cf65b8925ff2 9902 ERROR TEST-UNEXPECTED-FAIL | /tests/dom/tests/mochitest/pointerlock/test_pointerlock-api.html | file_movementXY.html: mozMovementX should be equal to eNow.screenX-ePrevious.screenX - got 10, expected 6
Chris, this seems to be basically permaorange since your landings today.
So that test is now commonly failing by being off by 45, which based on screen shots from mochitest timeouts on other tinderbox logs is exactly the width of the window manager's system menu bar plus the width of Firefox's window's title bar. So the first mouse move is being delivered before the window manager has finished entering fullscreen, and that's throwing off the test... Still working on a solution...
(In reply to Chris Pearce (:cpearce) from comment #41) > So that test is now commonly failing by being off by 45, which based on > screen shots from mochitest timeouts on other tinderbox logs is exactly the > width of the window manager's system menu bar plus the width of Firefox's > window's title bar. Sorry, really meant "being off on the y axis by 45" and I meant to say that's the *height* of the window manager's menu bar plus the *height* of Firefox's title bar....
Summary: Intermittent test_pointerlock-api.html | file_movementXY.html: mozMovementX should be equal to eNow.screenX-ePrevious.screenX - got 10, expected 6 → Intermittent test_pointerlock-api.html | file_movementXY.html: mozMovementX should be equal to eNow.screenX-ePrevious.screenX - got 10, expected 6 or got 14, expected 10
Blocks: 754451
So the problem is that we're dispatching mozfullscreenchange before the window's actually finished transitioning to fullscreen. We have this problem on MacOSX too. Changing the test's fullscreenchange listener to simply delay starting until window.screenX==0 && window.screenY==0 fixes the test, but we should really fix the underlying cause...
Depends on: 739749
Depends on: 756334
So the real problem is that we've not finished the fullscreen transition before the we're firing "mozfullscreenchange" event, when we start the test, and that's throwing out the screen coordinates used in this test. I'm working on a proper fix in bug 739749, but I'm worried that I'm not going to get it stabilized before I got away on vacation for 2 weeks on Friday, so I think we should land this fix which delays the start of the test until we're actually in fullscreen mode to keep philor and edmorely off my back. Successfully landing this will also prove my claim that as to the root cause of the pointerlock orange.
Assignee: nobody → cpearce
Status: NEW → ASSIGNED
Attachment #625589 - Flags: review?(bugs)
Attachment #625589 - Flags: review?(bugs) → review+
That fix was failing with: [POINTERLOCK] Starting file_movementXY.html 13248 ERROR TEST-UNEXPECTED-PASS | /tests/dom/tests/mochitest/pointerlock/test_pointerlock-api.html | file_movementXY.html: We should only receive fullscreenchange once we've finished fullscreen transition It seems window.screen{X,Y} can change during a JS execution context. So I took the liberty of pushing a fix to cache those before testing them. https://hg.mozilla.org/integration/mozilla-inbound/rev/1738e189377f
(In reply to Chris Pearce (:cpearce) from comment #371) > It seems window.screen{X,Y} can change during a JS execution context. So I > took the liberty of pushing a fix to cache those before testing them. > > https://hg.mozilla.org/integration/mozilla-inbound/rev/1738e189377f https://hg.mozilla.org/mozilla-central/rev/1738e189377f
Target Milestone: --- → mozilla15
(In reply to Chris Pearce (:cpearce) from comment #369) > Landed work around: > https://hg.mozilla.org/integration/mozilla-inbound/rev/e0ad3136549b https://hg.mozilla.org/mozilla-central/rev/e0ad3136549b
Target Milestone: mozilla15 → ---
(In reply to Chris Pearce (:cpearce) from comment #352) > Successfully landing this will also prove my claim that as to the root cause > of the pointerlock orange. Workaround seems to have worked, so you were right :-)
Whiteboard: [orange] → [orange][fixed by workaround for now]
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
Whiteboard: [orange][fixed by workaround for now] → [fixed by workaround for now]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: