Closed Bug 831024 Opened 12 years ago Closed 12 years ago

SpecialPowers.getBoolPref fails on device (but not desktop)

Categories

(Remote Protocol :: Marionette, defect)

Product:
Remote Protocol
Component:
Marionette
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: jedp, Unassigned)

References

Details

I am running a Jan 15 unagi eng build on device, and am forwarding tcp 2828. Using marionette, I can set a bool pref, but attempts to getBoolPref() traceback: In [1]: from marionette import Marionette In [2]: m = Marionette('localhost', 2828) In [3]: m.start_session() Out[3]: u'6-b2g' In [4]: m.execute_script('SpecialPowers.setBoolPref("dom.identity.syntheticEventsOk", true);', special_powers=True) In [5]: print "Pref is:", m.execute_script('SpecialPowers.getBoolPref("dom.identity.syntheticEventsOk");', special_powers=True) Pref is:--------------------------------------------------------------------------- JavascriptException Traceback (most recent call last) <ipython-input-5-f1240f3b9bf1> in <module>() ----> 1 print "Pref is:", m.execute_script('SpecialPowers.getBoolPref("dom.identity.syntheticEventsOk");', special_powers=True) /usr/local/lib/python2.7/site-packages/marionette/marionette.pyc in execute_script(self, script, script_args, new_sandbox, special_powers) 455 args=args, 456 newSandbox=new_sandbox, --> 457 specialPowers=special_powers) 458 return self.unwrapValue(response) 459 /usr/local/lib/python2.7/site-packages/marionette/marionette.pyc in _send_message(self, command, response_key, **kwargs) 220 return response[response_key] 221 else: --> 222 self._handle_error(response) 223 224 def _handle_emulator_cmd(self, response): /usr/local/lib/python2.7/site-packages/marionette/marionette.pyc in _handle_error(self, response) 255 raise ElementNotSelectableException(message=message, status=status, stacktrace=stacktrace) 256 elif status == ErrorCodes.JAVASCRIPT_ERROR: --> 257 raise JavascriptException(message=message, status=status, stacktrace=stacktrace) 258 elif status == ErrorCodes.XPATH_LOOKUP_ERROR: 259 raise XPathLookupException(message=message, status=status, stacktrace=stacktrace) JavascriptException: undefined: undefined Note that setBoolPref and getBoolPref are working on desktop for me. I have built b2g desktop myself using today's (Jan 15) gaia master and mozilla-central.
I forgot to make it 'return SpecialPowers.getBoolPref ...', but even with the return, it still crashes
This may be some OOP issue then, since the desktop build has OOP off by default.
I just tried on a local unagi build and couldn't reproduce the problem. I'll try the downloaded build.
I've confirmed this problem exists with the Jan 15 nightly, but not a local build made against mozilla-inbound. Hopefully this problem will resolve with the Jan 16 nightly; otherwise we'll need to investigate what's broken in mozilla-b2g18.
This continues to fail on a Jan 16 nightly, so I'll need to do some more digging.
I can reproduce this on a local build against mozilla-b2g18 as well, so there's some difference between mozilla-inbound and mozilla-b2g18 that's responsible. I don't think it's a Marionette difference, but I'll try to get a better error message out of it so we can move this to a B2G bug.
jgriffin fwiw I just confirmed the same on local mozilla-b2g18 (tip @1f0707eed4c3) using the latest marionette-client 0.5.16.
Also, fwiw, I am getting the error both on device and desktop builds of b2g18, whereas on a desktop build of m-c it was working yesterday. Maybe this will help bisect.
The error that is reported is quite unhelpful: E/GeckoConsole( 43): [JavaScript Error: "uncaught exception: Error getting pref"] This message is generated by SpecialPowers: http://mxr.mozilla.org/mozilla-central/source/testing/specialpowers/content/specialpowersAPI.js#794
Something is really rotten in Denmark here. The Marionette SpecialPowers unit test fails on a local build and on a build downloaded from releases.m.c, but it's currently passing on mozilla-b2g18 on TBPL. :(
I can get the test to pass locally by passing the --load-early flag. The load-early code was removed from m-i and m-c, but not yet from mozilla-b2g18. There is apparently some interaction between load time and SpecialPowers that was recently broken. I should be able to figure out a fix.
I just landed a fix from a different bug (https://hg.mozilla.org/releases/mozilla-b2g18/rev/b2f781164204, bug 820463) that didn't get uplifted to mozilla-b2g18. I think this should resolve this problem.
I pulled and built latest b2g18, which includes b2f781164204 - now I'm getting a different error that 'SpecialPowers' is not defined: JavascriptException: ReferenceError: SpecialPowers is not defined stacktrace: __marionetteFunc@chrome://marionette/content/marionette-listener.js:1820 TEST-UNEXPECTED-FAIL | test_identity.py TestIdentity.testAllowUnverified | @chrome://marionette/content/marionette-listener.js:1820 I can sense this is close to being fixed. So close!
(In reply to Jed Parsons [:jparsons] from comment #13) > I pulled and built latest b2g18, which includes b2f781164204 - now I'm > getting a different error that 'SpecialPowers' is not defined: > > > JavascriptException: ReferenceError: SpecialPowers is not defined > stacktrace: > > __marionetteFunc@chrome://marionette/content/marionette-listener.js:1820 > TEST-UNEXPECTED-FAIL | test_identity.py TestIdentity.testAllowUnverified | > @chrome://marionette/content/marionette-listener.js:1820 > > > I can sense this is close to being fixed. So close! This is a separate issue. We recently made a change to more strictly enforce the special_powers parameter to execute_script, because SpecialPowers is causing a memory leak which was impacting one of our partners' ability to perform stability tests. See bug 825802. There is likely an execute_script call in your test which uses SpecialPowers, but doesn't specify special_powers=True. I see one such case in https://github.com/mozilla/gaia-ui-tests/pull/249/files, line 125 of utils.py. In my own tests this appears to be working fine, so I'm going to close this, but please re-open if you continue to see problems.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Product: Testing → Remote Protocol
You need to log in before you can comment on or make changes to this bug.