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
Two things that we discovered after the initial update:
1) Fix the list of resolutions/DPIs needed
2) Update to the reflect the fact that each size must be manually crafted
Differential Revision: https://phabricator.services.mozilla.com/D158422
Although we do this updates fairly infrequently, these instructions seem like they'll be stable enough that it's worth writing them down.
Differential Revision: https://phabricator.services.mozilla.com/D155581
In days of old, it was safe to use -brand-short-name for this, as it always lined up with the installer's concept of BrandShortName. This changed when https://bugzilla.mozilla.org/show_bug.cgi?id=1378834 landed -- which started using "Firefox Nightly" for the nightly branding BrandShortName in the installer (but maintained "Nightly" as the in-product -brand-short-name). Changing one or the other of these is not really a viable option:
- Changing the installer's BrandShortName for Nightly to match -brand-short-name would cause shortcuts to simply be called "Nightly" -- which is the opposite of what the aforementioned bug wanted
- Changing -brand-short-name would cause a number of in-product strings to start using "Firefox Nightly" instead of "Nightly" -- which is probably undesirable for a few reasons, not the least of which is possible l10n implications
For these reasons, and the relatively short timeline I have to fix this, I'm taking the simplest and easiest path of introducing a new string specifically for in-product shortcut names, which lines up with the installer's values for BrandShortName. (We perhaps should also separate this out in the installer -- but it's unnecessary here, so I did not go to the trouble.)
Differential Revision: https://phabricator.services.mozilla.com/D156991
This allows us to fix a bug where when our current Private Browsing shortcuts are pinned to the Start Menu, they use the regular Firefox Visual Elements (which is the non-Private Browsing logo). I tried to make this as minimal and braindead as possible.
Differential Revision: https://phabricator.services.mozilla.com/D151538
These new icon files come from the PNG handed off from UX, which I then ran through a PNG -> ICO converter, and dropped any icon sizes that aren't also included in our `firefox.ico`. The ones that were kept are: 256x256, 48x48, 32x32, and 16x16.
Differential Revision: https://phabricator.services.mozilla.com/D147703
The new icon is not channel-specific, but I've kept it in branding
since it's possible that we'll distinguish in the future.
Differential Revision: https://phabricator.services.mozilla.com/D142396
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
When relanding Bug 1709697, all of the icons ended up as 0-byte files.
I can't explain this; it's hard to achieve this with a rebase. We
regenerate `Resources.pri` following the instructions in the
documentation.
This commit also moves to represent the package as "Mozilla Firefox",
which is consistent with how unpackaged versions appear in the Windows
UI. In the start menu, the application continues to be represented as
"Firefox" (no "Mozilla" vendor).
Finally, this commit also differentiates "Firefox Beta" from "Firefox"
in a few select places (while not changing branding and iconography).
Differential Revision: https://phabricator.services.mozilla.com/D122411
All files were generated by the "Visual Assets" panel in Visual
Studio. The file names are the Visual Studio default names. The
densities are a subset of the Visual Studio "Suggested" densities:
arbitrarily, I kept the -200 and dropped the -100 and -400
resolutions, and I kept the -256 and dropped the -16 and -48 target
sizes. We expect Windows to scale these appropriately, and we can
always adjust if we want higher resolutions in the future.
For MSIX, we will release Firefox Beta with a different package name.
We would prefer to brand Firefox Beta differently than Firefox
(Release), and at one point I included assets generated from the Beta
`Fx-Browser-Beta-icon-fullColor-512.png` file included in the Beta
Assets ZIP archive from https://mozilla.design/firefox/logos-usage/.
However, to simplify, I've removed these and made --channel=beta use
the same branding as --channel=release. This is consistent with the
general Desktop release process.
For the other release channels, assets were generated from
`content/about-logo@2x.png`, which is the highest resolution (384x384)
source I can find. These PNGs look better than those from
https://mozilla.design/firefox/logos-usage/ (to me): I theorize that
this is because they have already been quantized to 8bit colour and
that this avoids colour artifacts near edges.
Differential Revision: https://phabricator.services.mozilla.com/D116179
All files were generated by the "Visual Assets" panel in Visual
Studio. The file names are the Visual Studio default names. The
densities are a subset of the Visual Studio "Suggested" densities:
arbitrarily, I kept the -200 and dropped the -100 and -400
resolutions, and I kept the -256 and dropped the -16 and -48 target
sizes. We expect Windows to scale these appropriately, and we can
always adjust if we want higher resolutions in the future.
For MSIX, we will release Firefox Beta with a different package name.
We would prefer to brand Firefox Beta differently than Firefox
(Release), and at one point I included assets generated from the Beta
`Fx-Browser-Beta-icon-fullColor-512.png` file included in the Beta
Assets ZIP archive from https://mozilla.design/firefox/logos-usage/.
However, to simplify, I've removed these and made --channel=beta use
the same branding as --channel=release. This is consistent with the
general Desktop release process.
For the other release channels, assets were generated from
`content/about-logo@2x.png`, which is the highest resolution (384x384)
source I can find. These PNGs look better than those from
https://mozilla.design/firefox/logos-usage/ (to me): I theorize that
this is because they have already been quantized to 8bit colour and
that this avoids colour artifacts near edges.
Differential Revision: https://phabricator.services.mozilla.com/D116179
Allow for downstream projects such as Thunderbird to set different GUIDs for
AccessibleHandler to avoid clashes when both applications are installed.
The GUIDs themselves can be defined in confvars.sh or in branding/configure.sh
depending on the specific needs of the application. Fallback GUIDs are in
old-configure.
Differential Revision: https://phabricator.services.mozilla.com/D118124
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
