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

RESOLVED DUPLICATE of bug 871080

Status

Testing
Marionette
RESOLVED DUPLICATE of bug 871080
5 years ago
5 years ago

People

(Reporter: davehunt, Assigned: jgriffin)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

5 years ago
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?
(Reporter)

Comment 2

5 years ago
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?
(Assignee)

Comment 3

5 years ago
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
(Assignee)

Comment 5

5 years ago
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.
(Reporter)

Comment 6

5 years ago
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.
(Assignee)

Comment 7

5 years ago
(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.
(Assignee)

Comment 9

5 years ago
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.
(Assignee)

Comment 11

5 years ago
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
(Assignee)

Comment 12

5 years ago
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.
(Assignee)

Comment 13

5 years ago
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
(Assignee)

Comment 14

5 years ago
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
(Assignee)

Comment 15

5 years ago
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.
(Assignee)

Comment 16

5 years ago
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.
(Assignee)

Comment 17

5 years ago
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.
(Assignee)

Updated

5 years ago
Depends on: 871080
(Assignee)

Comment 18

5 years ago
Fixed by bug 871080
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 871080
You need to log in before you can comment on or make changes to this bug.