The current way to configure compare-locales has a lot of
assumptions that make our l10n system really stubborn.
The generic configuration is independent of python, and uses
toml files for configuration. They're still modular, but
there's only one file format.
See http://moz-l10n-config.readthedocs.io/en/latest/fileformat.html
for the specification.
Also fixes a few nits in filter.py, where we compared the
entity key as bool, which is false if we pass in ''.
Explicitly compare as "entity is None" to be precise about
when we're checking files.
MozReview-Commit-ID: 5TmfobaImF4
--HG--
extra : rebase_source : 84e56eb2076e74f79677df9e0368811579c1f173
The current way to configure compare-locales has a lot of
assumptions that make our l10n system really stubborn.
The generic configuration is independent of python, and uses
toml files for configuration. They're still modular, but
there's only one file format.
See http://moz-l10n-config.readthedocs.io/en/latest/fileformat.html
for the specification.
Also fixes a few nits in filter.py, where we compared the
entity key as bool, which is false if we pass in ''.
Explicitly compare as "entity is None" to be precise about
when we're checking files.
MozReview-Commit-ID: 5TmfobaImF4
--HG--
extra : rebase_source : 7c6feee0aa178315cc69fd6e8c7938365193224c
Intended use is a "kill-switch" for processing/upload of background telemetry.
MozReview-Commit-ID: CXhQtkxljAy
--HG--
extra : rebase_source : eabee231d46fe9d906fd2f9bf135edc845e12b1d
* removes old files mobile/android/config/mozconfigs/*/{release,l10n-release}
* updates merge day scripts (did some config dumping to verify, but didn't run migration)
* updates testing/mozharness/configs/single_locale/{staging_,}mozilla-{beta,release}_android-api-15.py to remove bogus mozconfig definition, which now comes from single_locale/tc_android-api-15.py
I could go on and look at configs/multi_locale, which appear to be unused, but I've got to draw a line somewhere.
MozReview-Commit-ID: 2zLYlMj0B9t
--HG--
extra : rebase_source : 2aee89720391890fd0c637589282af0066edb4bc
Right now SelectHelper and InputWidgetHelper are loaded in browser.js,
which means they only work for GeckoApp. This patch loads them in
PromptService.js instead, which means they will work in all windows. The
patch also changes some code in SelectHelper and InputWidgetHelper that
used to assume they are running under the browser.xul chrome window.
MozReview-Commit-ID: HveDzIzK1b4
To ensure SurfaceTexture contents are up to date before sending to compositor.
MozReview-Commit-ID: KdS8Z1vIP8y
--HG--
extra : rebase_source : ed4d58717a83de3b76f4543c73b6215abc1167ac
Right now SelectHelper and InputWidgetHelper are loaded in browser.js,
which means they only work for GeckoApp. This patch loads them in
PromptService.js instead, which means they will work in all windows. The
patch also changes some code in SelectHelper and InputWidgetHelper that
used to assume they are running under the browser.xul chrome window.
MozReview-Commit-ID: Jfe6ODyYKVf
For location permission, we first show a prompt for the website, then on
higher Android versions, we show a prompt for the app. For the app
prompt, right now we show that from GeckoView code in GeckoAppShell.
However, if we move the app prompt into ContentPermissionPrompt.js
alongside the website prompt, we can then remove the code in
GeckoAppShell and eliminate this app permission dependency from
GeckoView code.
MozReview-Commit-ID: GSCqClPROwn
Replace usages of GeckoAppShell.getContext() with
getApplicationContext() if possible, or the current Activity if the
usage expects an Activity context.
MozReview-Commit-ID: 9GOWszgEsQu
Instead of asking for permission in VideoCaptureDeviceInfoAndroid.java,
we now merely check for permission there. The actual permission prompt
now happens in WebrtcUI.js, using the new
"getUserMedia:ask-device-permission" and
"getUserMedia:got-device-permission" notifications.
MozReview-Commit-ID: DSVPjjW2JNR
