After the preceding changes, brand.dtd has no more actual users and may be removed.
One mochitest is switched to use a different DTD file which will still remain in the tree.
The dependency in aboutSupport.xhtml appears to have been accidentally left in when its localization was migrated to Fluent.
Differential Revision: https://phabricator.services.mozilla.com/D156668
At this point, no code in mozilla-central references these.
In comms-central, the string is still used, but provided there
by local brand.properties and brand.dtd files.
Depends on D141860
Differential Revision: https://phabricator.services.mozilla.com/D141861
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
This does many things:
1) stops producing (and consuming) `FennecJNI*` JNI wrappers
2) removes the :app and :thirdparty Gradle projects
3) removes relevant pieces of the Gradle target configuration
4) updates lints
5) purges old configurations
After this commit, the `mobile/android` project/application builds
only GeckoView.
Differential Revision: https://phabricator.services.mozilla.com/D46536
--HG--
extra : moz-landing-system : lando
We want to use the classic, non-adaptive icon again as our launcher icon on
Android versions prior to Oreo, as well as to continue using it in various
places within our app.
Unfortunately this means that we still have to provide duplicate resources for
those two purposes:
Because we don't want to use the adaptive icon internally, we can't use the same
resource directly for both internal usage and our launcher icon, because other-
wise on Oreo and above we'd receive the adaptive icon that way.
One possible workaround would have been to use the PNG files of our classic icon
directly as a drawable for internal useage and then create a differently named
XML bitmap for our launcher icon, which in turn would be overridden by the
adaptive icon on Oreo and above.
Unfortunately, modern usage demands that the launcher icon should be provided as
a mipmap resource, where XML bitmaps
- aren't officially supported
- unofficially work with some devices/launchers, but not all.
Therefore, our only choice is to provide separate drawables for our internal
icon and our launcher icon, even if prior to Android O both will have the same
contents. We'll also get rid of the separate round icon again, since
- on Android O and above, both round and non-round icons were using the same
adaptive icon anyway
- prior to Android O our normal icon is already round enough, but not round
enough to pass the lint check
--HG--
extra : rebase_source : 6c06c903f4fed2ef4aee3c5a915e18c437c5b510
extra : amend_source : ab3eab8e4dc2523a336aef2a4d2889ab7dbc76b9
extra : intermediate-source : 56f9803240157892066fa5b1703b8fe50c28020d
extra : source : 6183adcbfc9d81ab0cb854a4734a98f10a897d6b
We want to use the classic, non-adaptive icon again as our launcher icon on
Android versions prior to Oreo, as well as to continue using it in various
places within our app.
Unfortunately this means that we still have to provide duplicate resources for
those two purposes:
Because we don't want to use the adaptive icon internally, we can't use the same
resource directly for both internal usage and our launcher icon, because other-
wise on Oreo and above we'd receive the adaptive icon that way.
One possible workaround would have been to use the PNG files of our classic icon
directly as a drawable for internal useage and then create a differently named
XML bitmap for our launcher icon, which in turn would be overridden by the
adaptive icon on Oreo and above.
Unfortunately, modern usage demands that the launcher icon should be provided as
a mipmap resource, where XML bitmaps
- aren't officially supported
- unofficially work with some devices/launchers, but not all.
Therefore, our only choice is to provide separate drawables for our internal
icon and our launcher icon, even if prior to Android O both will have the same
contents. We'll also get rid of the separate round icon again, since
- on Android O and above, both round and non-round icon were using the same
adaptive icon anyway
- prior to Android O our normal icon is already round enough (ignoring the
Fennec icon for local developer builds)
--HG--
extra : source : 6183adcbfc9d81ab0cb854a4734a98f10a897d6b
extra : amend_source : dc14ea076aafd9d24fd5ee7aebcf71348812942c
Used the provided foreground layers and background color for the icons of
Release and Nightly.
Used the old icon and the provided background color for the icons of Beta and
Dev builds. Proper icons for them will be added in bug 1479724.
Added support for round icons which as per
https://developer.android.com/about/versions/nougat/android-7.1#circular-icons
can be required by certain launchers.
The old icons - /drawable/icon.png are still kept because they are used as
logos and also by SiteIdentityPopup.java.
MozReview-Commit-ID: EA9pojukhmw
--HG--
extra : rebase_source : d960bb0785b329a91493d9fe2c126549a5641189
Used the provided foreground layers and background color for the icons of
Release and Nightly.
Used the old icon and the provided background color for the icons of Beta and
Dev builds. Proper icons for them will be added in bug 1479724.
The old icons - /drawable/icon.png are still kept because they are used as
logos and also by SiteIdentityPopup.java.
MozReview-Commit-ID: EA9pojukhmw
--HG--
extra : rebase_source : e546ab143aaba73751c729c79926df3fb08c3b8c
When `--enable-official-branding` isn't set in mozconfig, `./mach configure` executes
mobile/android/branding/unofficial/configure.sh via `/bin/sh`. The `${USER:-unknown}`
syntax is POSIX, so this fix should work across all platforms.
MozReview-Commit-ID: C8T0ZgOFWgV
--HG--
extra : rebase_source : 32e0025f4a38fcf1113148cd6dbc4506af4a1ece