778256 - Geolocation mozSettings tests fail on Android; mozSettings is undefined

Status: RESOLVED WORKSFORME

(Core :: DOM: Geolocation, defect)

Description

[Matt Brubeck (:mbrubeck)]

The tests from bug 777594 fail on Android with the following error:

2970 ERROR TEST-UNEXPECTED-FAIL | /tests/dom/tests/mochitest/geolocation/test_mozsettings.html | an unexpected uncaught JS exception reported through window.onerror - TypeError: mozSettings is undefined at http://mochi.test:8888/tests/dom/tests/mochitest/geolocation/test_mozsettings.html:24
2973 ERROR TEST-UNEXPECTED-FAIL | /tests/dom/tests/mochitest/geolocation/test_mozsettingsWatch.html | an unexpected uncaught JS exception reported through window.onerror - TypeError: mozSettings is undefined at http://mochi.test:8888/tests/dom/tests/mochitest/geolocation/test_mozsettingsWatch.html:24

The tests were disabled temporarily in
https://hg.mozilla.org/integration/mozilla-inbound/rev/9b056f7ae1cd

Comment 1

[Ben Kelly [:bkelly, not reviewing]]

Attachment: Failure log on mac os 10.7

This problem is appearing on other platforms as well.  This was exposed on the try server when bug 847279 caused the test_mozsettings.html test case to be run at the beginning of mochitest-4 instead of at the end of mochitest-3.  It is easily reproducable on my machine.

Comment 2

[Ben Kelly [:bkelly, not reviewing]]

Attachment: Workaround for mozSettings creation race condition.

It appears that there is a race condition between the test case using mozSettings and the creation of the navigator.mozSettings node after setting dom.mozSettings.enabled to true.

This patch works around the problem by using a zero delay setTimeout() call.

Its unclear to me what the correct solution is for this.  Is it a bug in mozSettings creation or is this behavior expected?

Comment 3

[Ben Kelly [:bkelly, not reviewing]]

Note, any fix to test_mozsettings.html should also probably be applied to test_mozsettingsWatch.html as they use the same code structure.

Comment 4

[Reuben Morais [:reuben]]

I think bug 862353 is a better fix here.

Comment 5

[Ben Kelly [:bkelly, not reviewing]]

Comment on attachment 737965 [details] [diff] [review]
Workaround for mozSettings creation race condition.

Thanks Reuben!

I think it was probably incorrect for me to throw this in this bug at all.  The Android problem is probably unrelated to the recent timing changes.  Sorry for mucking up the bug history here.

Comment 6

[Ben Kelly [:bkelly, not reviewing]]

I verified that mozsettings still does not work on Android, even with the async loading changes.  Therefore, I opened bug 862666 to deal with these newer issues.  Sorry again for mucking up the history here.

Comment 7

[Ben Kelly [:bkelly, not reviewing]]

Android still fails after bug 862353.

https://tbpl.mozilla.org/?tree=Try&rev=7d3cdee236f3

I think these are unrelated.  The dependency for this bug was probably for the issue that was moved out to bug 862666.