Closed Bug 1051783 Opened 11 years ago Closed 11 years ago

OS X 10.6 mochitest-4 jobs contain "test_pointerlock-api.html | uncaught exception - NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMWindowUtils.sendMouseEvent] at specialpowersAPI.js:150"

Categories

(Core :: XPConnect, defect)

Product:
Core
Component:
XPConnect
Platform:
x86_64
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla34
Tracking Flags:
Tracking Status
firefox32 --- wontfix
firefox33 --- fixed
firefox34 --- fixed
firefox-esr24 --- unaffected
firefox-esr31 --- wontfix
b2g-v1.4 --- wontfix
b2g-v2.0 --- wontfix
b2g-v2.1 --- fixed

People

(Reporter: emorley, Assigned: martijn.martijn)

References

(
URL
)

Details

(Keywords: intermittent-failure)

Attachments

(1 file, 2 obsolete files)

1051783.diff
1.33 KB, patch
enndeakin
: review+
Details | Diff | Splinter Review
I've just noticed that there are failures within OS X 10.6 mochitest-4 jobs that are not turning the run orange. This bug is for fixing the failures; I'll file another for fixing the harness to report this as a failure (likely another structured logging regression). The failures started in: https://tbpl.mozilla.org/?tree=Mozilla-Inbound&rev=c682a6b343ba&jobname=snow.*mochitest-4 https://tbpl.mozilla.org/php/getParsedLog.php?id=44078966&tree=Mozilla-Inbound 22:10:56 INFO - [POINTERLOCK] Starting file_retargetMouseEvents.html 22:10:56 INFO - [974] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80040111: file /builds/slave/m-in-osx64-d-00000000000000000/build/dom/events/ContentEventHandler.cpp, line 110 22:10:56 INFO - [974] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80040111: file /builds/slave/m-in-osx64-d-00000000000000000/build/dom/events/ContentEventHandler.cpp, line 110 22:10:56 INFO - [974] WARNING: Should have pointer locked element, but didn't.: file /builds/slave/m-in-osx64-d-00000000000000000/build/dom/events/EventStateManager.cpp, line 3638 22:10:56 INFO - [974] WARNING: Should have pointer locked element, but didn't.: file /builds/slave/m-in-osx64-d-00000000000000000/build/dom/events/EventStateManager.cpp, line 3638 22:10:56 INFO - 476 INFO TEST-UNEXPECTED-FAIL | /tests/dom/tests/mochitest/pointerlock/test_pointerlock-api.html | uncaught exception - NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMWindowUtils.sendMouseEvent] at chrome://specialpowers/content/specialpowersAPI.js:150 22:10:56 INFO - JavaScript error: chrome://specialpowers/content/specialpowersAPI.js, line 150: NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMWindowUtils.sendMouseEvent] 22:10:57 INFO - [974] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80040111: file /builds/slave/m-in-osx64-d-00000000000000000/build/dom/events/ContentEventHandler.cpp, line 110 22:10:57 INFO - [POINTERLOCK] Finishing file_retargetMouseEvents.html Marking with the intermittent-failure keyword so this shows up on TBPL (though it occurs on every 10.6 run, not just intermittently).
Blocks: 1051791
Flags: needinfo?(bobbyholley)
Is this 10.6-only? If so, I don't think it's worth investigating. The regressing change (bug 1038844) is a change to the test harness only, so it's not likely that anything broke in the code we ship. Let's just disable the test on 10.6.
Flags: needinfo?(bobbyholley)
Another case where sendMouseEvent seems buggy on MacOSX 10.6 is bug 928678.
URL: http://dxr.mozilla.org/mozilla-centra...
Attached patch 1051783.diff (obsolete) — — Splinter Review
It turns out that Lion and Mountain Lion also were already disabled for this test.
Attachment #8474401 - Flags: review?(bobbyholley)
Assignee: nobody → martijn.martijn
I can reproduce this error also locally on my MacOS X 10.9.5 machine.
Attachment #8474401 - Flags: review?(bobbyholley)
Attached patch 1051783.diff (obsolete) — — Splinter Review
This skips the subtest that is causing this failure, this seems like a better interim solution for now. Even better would be, to fix the failure, of course.
Attachment #8474401 - Attachment is obsolete: true
Attachment #8474603 - Flags: review?(bobbyholley)
This test is doing: synthesizeMouseAtCenter(child, {type: "click"}, window); yet 'click' isn't a real mouse event, it's a dom event fired as the result of a mousedown and mouseup. You can fix that line by doing: synthesizeMouseAtCenter(child, {}, window); which fires a mousedown event and mouseup and will generate the click event the test is expecting.
Attached patch 1051783.diff — — Splinter Review
Thanks Neil, that makes the test indeed work.
Attachment #8474603 - Attachment is obsolete: true
Attachment #8474603 - Flags: review?(bobbyholley)
Attachment #8474611 - Flags: review?(enndeakin)
Attachment #8474611 - Flags: review?(enndeakin) → review+
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/dfed4f56ae9a
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla34
Sorry, I didn't think of assertions this could have caused (I should have done a tryserver with this test fix first). This is the assertion in question: 15:53:27 INFO - [989] ###!!! ASSERTION: Some mouse button down events are nested?: '!aDocument || !mMouseDownEventHandlingDocument', file /builds/slave/m-b30_14-osx64-d-0000000000000/build/dom/base/nsFocusManager.h, line 83 I don't think it's worth the effort to get this test working for b2g30. I mean, it was broken anyway. What do you think Neil?
Flags: needinfo?(martijn.martijn) → needinfo?(enndeakin)
I don't know what that error is, but bug 976673 removed that assertion.
Flags: needinfo?(enndeakin)
Definitely not worth spending any effort on IMO. Let's just wontfix the branches it fails on and get on with life.
status-b2g-v1.4: fixed → wontfix
status-b2g-v2.0: fixed → wontfix
status-firefox32: fixed → wontfix
status-firefox-esr31: fixed → wontfix
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: