Closed Bug 1533385 Opened 5 years ago Closed 5 years ago

Allow setting environment variables and about:config prefs using a local file

Categories

(GeckoView :: General, defect, P2)

Unspecified
Android
defect

Tracking

(firefox68 fixed)

RESOLVED FIXED
mozilla68
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.

Ah, I thought this worked without root for non-system properties, but apparently not. Bummer.

Summary: Allow setting environment variables vi `adb shell setprop` → Allow setting environment variables via `adb shell setprop`

Chrome allows developers to set environment variables using a local file.

OS: All → Android
Priority: -- → P2
Summary: Allow setting environment variables via `adb shell setprop` → Allow setting environment variables and about:config prefs using a local file

(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.

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

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.

Assignee: nobody → snorp

gbrown: could you f? my proposal at https://phabricator.services.mozilla.com/D23518#734419 -- I'd like to ensure I'm not missing something.

(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!

Flags: needinfo?(gbrown)

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"

Flags: needinfo?(gbrown)
Attachment #9051008 - Attachment description: Bug 1533385 - Read env and prefs for GeckoView from filesystem in debuggable apps r?#geckoview-reviewers → Bug 1533385 - Read debug config for GeckoView from filesystem in debuggable apps r?#geckoview-reviewers,nalexander

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.

Note to self: this will want uplift to 67 in order to be consumed by Fenix.

For folks following along at home, documentation is here: https://mozilla.github.io/geckoview/tutorials/automation.html.

Assignee: snorp → nalexander
Status: NEW → ASSIGNED
Attachment #9051008 - Attachment is obsolete: true
Attachment #9051008 - Attachment is obsolete: false
Attachment #9051008 - Attachment is obsolete: true
Pushed by nalexander@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/91b055c0dadb
Make GeckoView read configuration options from filesystem. r=droeh
Pushed by nalexander@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/47d793fbd8cc
Make GeckoView read configuration options from filesystem. r=droeh

Relanded after try builds last night. Fingers crossed!

Flags: needinfo?(nalexander)
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla68
Regressions: 1542393
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Target Milestone: mozilla68 → ---
Attachment #9055352 - Attachment description: Bug 1533385 - Make GeckoView read configuration options from filesystem. r?droeh → Bug 1533385 - Make GeckoView read configuration options from filesystem.

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?

Flags: needinfo?(snorp)
Flags: needinfo?(nalexander)

(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.

Flags: needinfo?(snorp)

Hmm, I thought I had actually relanded this but apparently not?

Pushed by jwillcox@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/b978367ef7bb
Make GeckoView read configuration options from filesystem. r=droeh
Status: REOPENED → RESOLVED
Closed: 5 years ago5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla68
Blocks: 1547717
Blocks: 1552519
Blocks: 1554256
Blocks: 1556793
Blocks: 1557805
Blocks: 1584400
Blocks: 1577850

This has landed and is looking fine. Clearing NI.

Flags: needinfo?(nalexander)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: