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"

RESOLVED FIXED in Firefox 33

Status

()

defect
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: emorley, Assigned: martijn.martijn)

Tracking

({intermittent-failure})

Trunk
mozilla34
x86_64
macOS
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(firefox32 wontfix, firefox33 fixed, firefox34 fixed, firefox-esr24 unaffected, firefox-esr31 wontfix, b2g-v1.4 wontfix, b2g-v2.0 wontfix, b2g-v2.1 fixed)

Details

()

Attachments

(1 attachment, 2 obsolete attachments)

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
Duplicate of this bug: 1040897
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.
Posted 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)
Posted 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.
Posted patch 1051783.diffSplinter 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: 5 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.
You need to log in before you can comment on or make changes to this bug.