Intermittent test_pointerlock-api.html | uncaught JS exception - ReferenceError: start is not defined at pointerlock_utils.js:58

RESOLVED FIXED in mozilla18

Status

()

defect
RESOLVED FIXED
7 years ago
6 years ago

People

(Reporter: emorley, Assigned: cpearce)

Tracking

({intermittent-failure})

Trunk
mozilla18
x86
Windows 7
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

7 years ago
Rev3 WINNT 6.1 mozilla-inbound debug test mochitests-3/5 on 2012-10-01 00:18:10 PDT for push 1c930f35d954

slave: talos-r3-w7-082

https://tbpl.mozilla.org/php/getParsedLog.php?id=15695981&tree=Mozilla-Inbound

{
[POINTERLOCK] Starting file_allowPointerLockSandboxFlag.html
++DOMWINDOW == 101 (09A482B0) [serial = 8824] [outer = 09A48878]
15103 ERROR TEST-UNEXPECTED-FAIL | /tests/dom/tests/mochitest/pointerlock/test_pointerlock-api.html | an unexpected uncaught JS exception reported through window.onerror - ReferenceError: start is not defined at http://mochi.test:8888/tests/dom/tests/mochitest/pointerlock/pointerlock_utils.js:58
JavaScript error: http://mochi.test:8888/tests/dom/tests/mochitest/pointerlock/pointerlock_utils.js, line 58: start is not defined
JS Component Loader: ERROR chrome://global/content/BrowserElementChild.js:175
                     TypeError: content is null
WARNING: NS_ENSURE_SUCCESS(res, res) failed with result 0x80004005: file e:/builds/moz2_slave/m-in-w32-dbg/build/content/base/src/nsDocument.cpp, line 9012
WARNING: NS_ENSURE_SUCCESS(res, res) failed with result 0x80004005: file e:/builds/moz2_slave/m-in-w32-dbg/build/content/base/src/nsDocument.cpp, line 9012
++DOMWINDOW == 102 (103E3208) [serial = 8825] [outer = 09A48878]
WARNING: No outer window available!: file e:/builds/moz2_slave/m-in-w32-dbg/build/dom/base/nsGlobalWindow.cpp, line 9175
WARNING: No outer window available!: file e:/builds/moz2_slave/m-in-w32-dbg/build/dom/base/nsGlobalWindow.cpp, line 9175
WARNING: No outer window available!: file e:/builds/moz2_slave/m-in-w32-dbg/build/dom/base/nsGlobalWindow.cpp, line 9175
JS Component Loader: ERROR chrome://global/content/BrowserElementChild.js:175
                     TypeError: content is null
WARNING: ShouldLockPointer(): Document is sandboxed and doesn't allow pointer-lock: file e:/builds/moz2_slave/m-in-w32-dbg/build/content/base/src/nsDocument.cpp, line 9701
WARNING: NS_ENSURE_SUCCESS(res, res) failed with result 0x80004005: file e:/builds/moz2_slave/m-in-w32-dbg/build/content/base/src/nsDocument.cpp, line 9012
WARNING: NS_ENSURE_SUCCESS(res, res) failed with result 0x80004005: file e:/builds/moz2_slave/m-in-w32-dbg/build/content/base/src/nsDocument.cpp, line 9012
15104 INFO TEST-PASS | /tests/dom/tests/mochitest/pointerlock/test_pointerlock-api.html | file_allowPointerLockSandboxFlag.html: Pointer should only have been locked once. Without allow-pointer-lock flag, a sandboxed document should not be able to lock the pointer - 1 should equal 1
}

Caused by bug 784402.
Comment hidden (Legacy TBPL/Treeherder Robot)
Comment hidden (Legacy TBPL/Treeherder Robot)
Comment hidden (Legacy TBPL/Treeherder Robot)
Comment hidden (Legacy TBPL/Treeherder Robot)
Comment hidden (Legacy TBPL/Treeherder Robot)
Comment hidden (Legacy TBPL/Treeherder Robot)

Comment 7

7 years ago
Chris, could this have been caused by the recent pointerlock change that landed?
Comment hidden (Legacy TBPL/Treeherder Robot)
(Assignee)

Comment 9

7 years ago
This doesn't look like it's caused by my recent pointer lock changes, they landed on inbound at:
bug 794725: Sun Sep 30 13:17:07 2012 PDT
Bug 782729: Mon Sep 24 16:46:02 2012 PDT 

I agree with Ed Morely, this is an original regression from bug 784402.

The failure is pretty simple; the test added in bug 784402 [1] includes pointerlock_utils.js [2], and pointerlock_utils.js assumes that anything that includes it will define a function called "start", and it tries to call that in a load event handler. But the new test added by bug 784402 doesn't define "start", it instead has a function "startTest" that begins the test after an iframe has loaded.

So we're throwing a JS exception due to referencing an undefined property "start" in a child window. The fact that our test harness didn't report this as perma-orange is disturbing.

A simple fix is to change pointerlock_utils.js to not call "start" if it isn't defined, i.e. assume the test file including pointerlock_utils.js will start itself if it doesn't define a "start" function.

I'll make a patch.

[1] http://mxr.mozilla.org/mozilla-central/source/dom/tests/mochitest/pointerlock/file_allowPointerLockSandboxFlag.html?force=1
[2] http://mxr.mozilla.org/mozilla-central/source/dom/tests/mochitest/pointerlock/pointerlock_utils.js
(Assignee)

Comment 10

7 years ago
Prevents the exception locally.
Assignee: nobody → cpearce
Status: NEW → ASSIGNED
Attachment #667667 - Flags: review?(ehsan)
Comment hidden (Legacy TBPL/Treeherder Robot)

Comment 12

7 years ago
Comment on attachment 667667 [details] [diff] [review]
Patch: Don't assume every mochitest that includes pointerlock_utils.js defines a 'start' function to begin its tests.

Review of attachment 667667 [details] [diff] [review]:
-----------------------------------------------------------------

Heh, nice!
Attachment #667667 - Flags: review?(ehsan) → review+
(Reporter)

Comment 14

7 years ago
https://hg.mozilla.org/mozilla-central/rev/972c376d08b5
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla18
Whiteboard: [orange]
Comment hidden (Legacy TBPL/Treeherder Robot)
You need to log in before you can comment on or make changes to this bug.