Closed Bug 836253 Opened 11 years ago Closed 11 years ago

Marionette is not available on nightly mozilla-central desktop client builds

Categories

(Remote Protocol :: Marionette, defect)

Product:
Remote Protocol
Component:
Marionette
Platform:
ARM
Gonk (Firefox OS)
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 871080

People

(Reporter: davehunt, Assigned: jgriffin)

References

Details

Steps to reproduce (on Mac):

$ wget http://ftp.mozilla.org/pub/mozilla.org/b2g/nightly/latest-mozilla-central/en-US/b2g-21.0a1.en-US.mac64.dmg
$ hdiutil attach b2g-21.0a1.en-US.mac64.dmg
$ cp -R /Volumes/B2G/B2G.app .
$ echo -e "user_pref('marionette.force-local', true);\n" >> B2G.app/Contents/MacOS/gaia/profile/user.js
$ echo -e "user_pref('marionette.defaultPrefs.enabled', true);\n" >> B2G.app/Contents/MacOS/gaia/profile/user.js
$ open B2G.app

... wait for Firefox OS desktop client to start ...

$ virtualenv env
$ source env/bin/activate
$ pip install marionette_client
$ python

>>> from marionette import Marionette
>>> m = Marionette()
>>> m.start_session()

... hangs ...

Repeat these steps with http://ftp.mozilla.org/pub/mozilla.org/b2g/nightly/latest-mozilla-b2g18/en-US/b2g-18.0.en-US.mac64.dmg and you get a session.
Using today's build, the marionette server is running, but the log ends with:

1360076304128	Marionette	INFO	could not load listener into content for page: chrome://browser/content/shell.xul

So it can't load a content listener into the b2g context. We usually see this when there's a problem in the gaia-side, but I don't know how to get the runtime B2G logs. Do you?
I've just confirmed this is still the case. I've no idea how to get the runtime logs. Are we running automation against the Firefox OS desktop client builds? I thought we were... Do you know anyone we could CC on this bug to get some traction?
We are not running any tests against desktop B2G builds.  It will probably be up to Malini or myself to figure out what's going wrong here.
This is still the case, and applies to the linux builds as well, so it's not platform specific
Ah, I missed the 'nightly' part of this.  We don't enable Marionette at all on nightly builds due to security concerns...some users use nightlies as their primary browser, and we don't want them unknowingly exposing themselves to some unquantified risk.
Is it something that can be enable post-build? This was originally raised so I could use these nightly builds as a basis for documentation on running the Gaia UI tests against desktop builds. I have since written this documentation based on the b2g18 builds.
(In reply to Dave Hunt (:davehunt) from comment #6)
> Is it something that can be enable post-build?

Not as it stands.  It's possible we could create a Marionette extension that would have the same effect, at some maintenance cost.

The security guys are very unwilling to make Marionette part of the build for any build that users are likely to download.
NOTE: This is only for desktop, I dont know of a good way for Mobile which is the scariest place!

Speaking to gkw (at MozCampAsia) there is a way that we can get this in to opt-builds for Desktop, at least. I hope he remembers the conversation :)

All of the following need to be done before security would consider it

* require a command line arg for starting up Firefox for marionette to get started
** e.g firefox.exe --marionette
* Marionette prefs should not be in prefs.js
** e.g. Something like MozProfile, or manually, needs to add prefs
* Add something, and this is a minor thing, that allows websites to see that they are being accessed by Marionette/WebDriver
** e.g. https://code.google.com/p/selenium/source/browse/javascript/firefox-driver/extension/content/dommessenger.js#95

The items above are currently how Google Chrome and Opera do the same thing.
gkw, do you think we need to do this for per-commit opt builds, vs nightly and release builds?  There isn't an update channel for per-commit opt builds, so I think the chances of end users using them are about zilch.
> All of the following need to be done before security would consider it

Basically we'd need to put enough roadblocks for conventional users not to be hit with attacks which silently activate Marionette on Nightly, when it is run the conventional way (i.e. without any extra prefs / runtime args).

I would feel that the options/workarounds listed by David in comment 8 seem to be a reasonable compromise, and am open to other suggestions, too.

(In reply to Jonathan Griffin (:jgriffin) from comment #9)
> gkw, do you think we need to do this for per-commit opt builds, vs nightly
> and release builds?  There isn't an update channel for per-commit opt
> builds, so I think the chances of end users using them are about zilch.

While David and I were discussing this, I believe we were referring to released/beta/aurora/nightly builds, and the workarounds would generally be easy for devs to script, yet difficult enough for Nightly users to have it "accidentally" enabled.

I'm thus not very convinced that we should make per-commit opt builds (tinderbox-builds) differ too much from the corresponding Nightly builds, especially since AIUI they use similar mozconfigs. It might make testing a little more complex.
I'm going to look at this; we need it for bug 866908.  Marionette is enabled in these builds, but something bad is happening.
Assignee: nobody → jgriffin
Blocks: 866908
Of course I can't reproduce this with a local build.  :(  Will need to do some spelunking to see what's different between my local build and the buildbot one.
It looks like this may have something to do with PGO optimization.  I've disabled that in a tryserver job:  https://tbpl.mozilla.org/?tree=Try&rev=6ca26b6be57b
No go.  Here's another try run with some more debugging info added, so hopefully I can tell where it's getting stuck:  https://tbpl.mozilla.org/?tree=Try&rev=da86788f0df4
The only thing I've been able to determine is that marionette-listeners.js is never loaded, but I haven't yet been able to figure out why.
A little bit of progress.  marionette-listener.js is dying because it loads specialpowersAPI.js, and that file is dying at this import:

http://mxr.mozilla.org/mozilla-central/source/testing/specialpowers/content/specialpowersAPI.js#12

Cu.import("resource://specialpowers/MockFilePicker.jsm");

Why this is happening, and why it only happens with buildbot builds and not local builds, is still a mystery.
This is possibly a JAR file problem of some sort.

In a buildbot desktop B2G build, MockFilePicker.jsm is the last file in marionette.jar, and doesn't get loaded properly.  In a local build, there's no marionette.jar file by default; instead, marionette files (including MockFilePicker.jsm) get loaded via symlinks from dist/bin/chrome/...

In desktop Firefox, Marionette files are part of omni.ja(r), and Marionette files are smack in the middle of this, and don't have any problem being loaded.
Depends on: 871080
Fixed by bug 871080
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → DUPLICATE
Product: Testing → Remote Protocol
You need to log in before you can comment on or make changes to this bug.