Allow setting environment variables and about:config prefs using a local file
Categories
(GeckoView :: General, defect, P2)
Tracking
(firefox68 fixed)
Tracking | Status | |
---|---|---|
firefox68 | --- | fixed |
People
(Reporter: snorp, Assigned: nalexander)
References
(Blocks 5 open bugs)
Details
Attachments
(1 file, 1 obsolete file)
Right now we have to use intents, which is clumsy, and requires opt-in from apps. We should be able to use adb shell setprop org.mozilla.geckoview_example.env MOZ_LOG=<stuff>
instead.
Reporter | ||
Comment 1•6 years ago
|
||
Ah, I thought this worked without root for non-system properties, but apparently not. Bummer.
Reporter | ||
Updated•6 years ago
|
Comment 2•6 years ago
|
||
Chrome allows developers to set environment variables using a local file.
Assignee | ||
Comment 3•6 years ago
|
||
(In reply to Chris Peterson [:cpeterson] from comment #2)
Chrome allows developers to set environment variables using a local file.
Kinda sorta. After setting a flag in Chrome itself, you can launch Chrome with parameters (but not environment variables, AFAIK). However, you can only do that for WebViews on devices that are marked as "debug", which basically don't exist in the wild. That is, I can't find a way to launch a WebView with Chrome flags set on any of the Fire TV devices I'm testing, leading to horrendous work-arounds for setting proxies in my local version of Firefox TV.
Reporter | ||
Comment 4•6 years ago
|
||
It looks like chrome reads /data/local/tmp/chrome-command-line
after you enable this via chrome://flags
[1]. I propose we do the same (/data/local/tmp/geckoview-command-line
) as well as .../geckoview-env
and .../geckoview-prefs
. Maybe we only enable in debuggable apps? I would like to avoid adding yet another runtime setting for this.
[1] https://stackoverflow.com/questions/29280796/run-google-chrome-with-flags-on-android
Reporter | ||
Comment 5•6 years ago
|
||
This allows you to put environment variables (one per line) in
/data/local/tmp/geckoview-env. If the containing app is debuggable,
these environment variables will be merged with the standard ones
when Gecko is started.
Similar machinery is also added for prefs, using
/data/local/tmp/geckoview-prefs. The format there is the same as
other default prefs file, e.g. 'pref("foo.bar.baz",false);'. These
will be merged with the default prefs branch at startup under the
same conditions mentioned above.
Reporter | ||
Updated•6 years ago
|
Assignee | ||
Comment 6•6 years ago
|
||
gbrown: could you f? my proposal at https://phabricator.services.mozilla.com/D23518#734419 -- I'd like to ensure I'm not missing something.
Assignee | ||
Comment 7•6 years ago
|
||
(In reply to Nick Alexander :nalexander [he/him] from comment #6)
gbrown: could you f? my proposal at https://phabricator.services.mozilla.com/D23518#734419 -- I'd like to ensure I'm not missing something.
And now flagging gbrown as well!
Comment 8•6 years ago
|
||
Thanks Nick. I'm glad to see the discussion, but don't have anything to add.
To provide context from test automation, I'll just mention that we currently start TRA mochitests with:
am start -W -n org.mozilla.geckoview.test/org.mozilla.geckoview.test.TestRunnerActivity -a android.intent.action.Main --es env9 MOZ_CRASHREPORTER_NO_REPORT=1 --es env8 MOZ_UPLOAD_DIR=/sdcard/tests/mozlog --es args "-no-remote -profile /sdcard/tests/profile//" --es env3 DISABLE_UNSAFE_CPOW_WARNINGS=1 --es env2 R_LOG_VERBOSE=1 --es env1 XPCOM_DEBUG_BREAK=stack --es env0 MOZ_CRASHREPORTER=1 --es env7 R_LOG_DESTINATION=stderr --es env6 MOZ_CRASHREPORTER_SHUTDOWN=1 --es env5 MOZ_IN_AUTOMATION=1 --es env4 MOZ_DISABLE_NONLOCAL_CONNECTIONS=1 --ez use_multiprocess True --es env11 MOZ_HIDE_RESULTS_TABLE=1 --es env10 R_LOG_LEVEL=6 -d "http://mochi.test:8888/tests?autorun=1&closeWhenDone=1&logFile=%2Fsdcard%2Ftests%2Flogs%2Fmochitest.log&fileLevel=INFO&consoleLevel=INFO&hideResultsTable=1&manifestFile=tests.json&dumpOutputDirectory=%2Fsdcard%2Ftests"
Updated•6 years ago
|
Assignee | ||
Comment 9•6 years ago
|
||
The configuration file format is YAML and looks like:
prefs:
foo.bar.boolean: true
foo.bar.string: "string"
foo.bar.int: 500
env:
MOZ_LOG: nsHttp:5
args: [--marionette]
By default, if the consuming App is debuggable, GeckoView will read
configuration from /data/local/tmp/$PACKAGE-geckoview-config.yaml at
startup.
For consumers (including browsers) that want to allow the underlying
GeckoView to be remote controlled in some way, the
GeckoRuntimeSettings.Builder.configFilePath()
method allows to avoid
the default behaviour depending on the android:debuggable
flag. For
example, release versions of Firefox for Android will want to allow
this configuration when appropriate App-level settings are toggled.
The additional configuration is appended after any existing configuration
methods, e.g., after anything specified using Intent argument extras
or existing GeckoRuntimeSettings.Builder
methods.
Assignee | ||
Comment 10•6 years ago
|
||
Note to self: this will want uplift to 67 in order to be consumed by Fenix.
Assignee | ||
Comment 11•6 years ago
|
||
For folks following along at home, documentation is here: https://mozilla.github.io/geckoview/tutorials/automation.html.
Assignee | ||
Updated•6 years ago
|
Updated•6 years ago
|
Assignee | ||
Updated•6 years ago
|
Comment 12•6 years ago
|
||
Comment 13•6 years ago
|
||
Backed out for breaking gv-junit at org.mozilla.geckoview.test
Push with failures: https://treeherder.mozilla.org/#/jobs?repo=autoland&resultStatus=testfailed%2Cbusted%2Cexception&revision=91b055c0dadb8032a44fb659695d6487c7d43d5e
Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=238003350&repo=autoland&lineNumber=1429
Backout: https://hg.mozilla.org/integration/autoland/rev/b1d1995b5e6a700b4f9600a76b5268ee62003f97
Comment 14•6 years ago
•
|
||
There is also this reftest failure https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=238004807&repo=autoland&lineNumber=1415
and the following exceptions:
Comment 15•6 years ago
|
||
Assignee | ||
Comment 16•6 years ago
|
||
Relanded after try builds last night. Fingers crossed!
Comment 17•6 years ago
|
||
bugherder |
Comment 18•6 years ago
|
||
Backed out on request by nalexander.
https://hg.mozilla.org/integration/autoland/rev/9bc397e8199db4df590f7307b8ba6afb32c9ce96
Updated•6 years ago
|
Assignee | ||
Comment 19•6 years ago
|
||
Phab won't let me make myself a blocking reviewer. I can't really see the interdiff for this yet -- thank Phab, yet again -- but it doesn't look like what I expect. snorp, did you not land the JAR in the tree in this patch?
Reporter | ||
Comment 20•6 years ago
|
||
(In reply to Nick Alexander :nalexander [he/him] from comment #19)
Phab won't let me make myself a blocking reviewer. I can't really see the interdiff for this yet -- thank Phab, yet again -- but it doesn't look like what I expect. snorp, did you not land the JAR in the tree in this patch?
We didn't end up doing that. It's problematic for apps that want to also use snakeyaml themselves.
I think the build problem is an anomaly with some local environments -- it worked fine for me in an Ubuntu 18.0.4 VM, in automation, and my main Fedora machine. My guess is that we may be able to get it working for people by using Oracle Java or a newer build of openjdk.
Reporter | ||
Comment 21•6 years ago
|
||
Hmm, I thought I had actually relanded this but apparently not?
Comment 22•6 years ago
|
||
Comment 23•6 years ago
|
||
bugherder |
Updated•6 years ago
|
Assignee | ||
Comment 24•5 years ago
|
||
This has landed and is looking fine. Clearing NI.
Description
•