This modernizes an old part of the build system to not require
build-time localization at all. That's generally preferable.
The most significant changes to the in-product functionality is to
make import localize HTML so that we can use Fluent's `data-l10n-id`.
The locale used is the user's current locale. This is different than
the existing approach, which always uses the build-time (repack)
locale. I believe this is a strictly superior user experience and it
may lead to future improvements where-in the default bookmarks become
truly dynamic and vary with the user's chosen locale rather than being
point-in-time decisions.
I tried to restrict these changes to only applen when we import the
default bookmarks, but I think the various layers of flags no longer
achieve this restriction in practice and the formatting and
localization will apply to all imported `bookmarks.html` files. Since
we don't anticipate (nor ourselves write) these new things in
(respectively, to) `bookmarks.html`, and the file is already
user-controlled, I don't think this exposes any meaningful change in
functionality (or in security surface).
Some notes:
1) There's no migration of `.inc` -> `.ftl` because this is the lone
`.inc` file.
2) I elected to prefix all strings with `default-bookmarks-`, since
the existing names were very short and likely to collide (now or in
the future).
3) I elected to change the HTML file name for easier searching.
4) Since the `default-bookmarks.html` file is product-specific and the
existing tests are in `toolkit/`, I elected to not test the file
directly in automation.
5) We removed the explicit locale (or equivalent `%LOCALE%`) since
Mozilla properties will redirect to the appropriate language
automatically.
Differential Revision: https://phabricator.services.mozilla.com/D135816
While mingw builds don't require user32 and advapi32 explicitly, it doesn't
hurt for them to be there (and they're required for clang-cl build).
Likewise, while clang-builds don't require uuid and userenv explicitly
because they're pulled in via #pragmas in the source code, mingw doesn't
support those #pragmas and needs them explicitly, which doesn't hurt the
clang-cl builds.
Differential Revision: https://phabricator.services.mozilla.com/D134737
While mingw builds don't require user32 and advapi32 explicitly, it doesn't
hurt for them to be there (and they're required for clang-cl build).
Likewise, while clang-builds don't require uuid and userenv explicitly
because they're pulled in via #pragmas in the source code, mingw doesn't
support those #pragmas and needs them explicitly, which doesn't hurt the
clang-cl builds.
Differential Revision: https://phabricator.services.mozilla.com/D134737
Acording to crash reports, obsfucating the NSS DB locations did not help, so
this patch un-does the changes and un-migrates any migrated DB locations.
Differential Revision: https://phabricator.services.mozilla.com/D129323
Startup migrations pass the "ALL" constant, which unlike what you might expect is
not just an OR'd together set of all the other flags - so it needs to be checked
explicitly.
Differential Revision: https://phabricator.services.mozilla.com/D129282
Some crash reports appear to be indicating that initializing NSS' certificate
and key databases is taking on the order of minutes in some cases, which is
unexpected. One hypothesis is that third-party software is opening these DBs at
the same time that NSS is operating on them, causing contention and thus
slowness. This patch experimentally (in Nightly only) renames these DBs in the
hopes that third-party software might not recognize them as the DBs it's
looking for, and will thus leave them alone.
Differential Revision: https://phabricator.services.mozilla.com/D126028
Some crash reports appear to be indicating that initializing NSS' certificate
and key databases is taking on the order of minutes in some cases, which is
unexpected. One hypothesis is that third-party software is opening these DBs at
the same time that NSS is operating on them, causing contention and thus
slowness. This patch experimentally (in Nightly only) renames these DBs in the
hopes that third-party software might not recognize them as the DBs it's
looking for, and will thus leave them alone.
Differential Revision: https://phabricator.services.mozilla.com/D126028
Some crash reports appear to be indicating that initializing NSS' certificate
and key databases is taking on the order of minutes in some cases, which is
unexpected. One hypothesis is that third-party software is opening these DBs at
the same time that NSS is operating on them, causing contention and thus
slowness. This patch experimentally (in Nightly only) renames these DBs in the
hopes that third-party software might not recognize them as the DBs it's
looking for, and will thus leave them alone.
Differential Revision: https://phabricator.services.mozilla.com/D126028
These tests are excluded from android test runs in moz.build. Including
an explicit annotation in each manifest avoids scheduling confusion.
browser-chrome and plain-chrome tests in browser/ are of no concern,
since those test types are never scheduled on android.
Differential Revision: https://phabricator.services.mozilla.com/D125266
This is most commonly as a result of CU.evalInSandbox which
allows an arbitrary filename but when omitted will default
to the filename of the test, which is a filesystem path
and thus is disallowed.
Differential Revision: https://phabricator.services.mozilla.com/D122246
This is most commonly as a result of CU.evalInSandbox which
allows an arbitrary filename but when omitted will default
to the filename of the test, which is a filesystem path
and thus is disallowed.
Differential Revision: https://phabricator.services.mozilla.com/D122246
