Following a suggestion from :mkmelin, this seems like an optimal solution: the overriding/duplication in m-c is removed, and all users get a more powerful default choice that they're still able to override with their own, should they so wish.
For clarity and to match other `about:` pages, the shared code is placed under `toolkit/content/`, and all content under `docshell/resources/` is removed.
Differential Revision: https://phabricator.services.mozilla.com/D156478
To support and enable the migration, quite a bit of refactoring is needed.
Many of the localised error messages are in fact fragments of HTML, including messages with nesting not supported by Fluent. In the FTL, these have each been split up into multiple messages using a custom migration transform (included directly in the script). This allows for localisers to work with the messages without HTML syntax, but does require the messages' structures to be maintained elsewhere. To that effect, the JS file represents messages as arrays of `[tagName, l10nId, l10nArgs]` tuples from which it builds the messages' elements. This fixex bug 1621895.
Though extensive, the refactoring done here is for the most part limited to what's required by the Fluent migration. For instance, not all issues raised in bug 1722896 are resolved here. Places where the structure was sufficiently messy to have introduced bugs or dead code have been cleaned up a bit, though.
This variant of netError that's used by the browser is not itself overridden by anyone else, which allows for it to be tackled first and independently of the docshell and mobile variants. As a part of its content is still passed in as a query parameter, it's possible that later refactors of the rest of the netError system will allow for further clean-up here.
Differential Revision: https://phabricator.services.mozilla.com/D155951
Previously most 'reasons' could only be seen if using a debugger, which
was not helpful when there was a problem in CI.
Depends on D158703
Differential Revision: https://phabricator.services.mozilla.com/D158704
This will resolve issues of drive letter uppercase/lowercase mismatch
causing the venv/site to be considered 'out-of'date'.
Differential Revision: https://phabricator.services.mozilla.com/D158703
Relevant strings from both browser.ftl and browser.properties are collected into a new contentCrash.ftl, which is only loaded when needed.
Differential Revision: https://phabricator.services.mozilla.com/D158649
- Added the variable `OPTIONAL_BROWSER_PACKAGES`, which contains
a list of packages which should, if possible, be installed with
zypper. If that isn't possible because the package can't be
found, just display a warning and continue.
- Add `gconf2-devel` to `OPTIONAL_BROWSER_PACKAGES`, since
gconf2-devel is not available in Tumbleweed repos and also
not required to build Firefox.
Differential Revision: https://phabricator.services.mozilla.com/D152217
This is a condition that happens when going through the js/src code path
in build/moz.configure/init.configure:mozconfig.
Differential Revision: https://phabricator.services.mozilla.com/D157769
This migration creates the first FTL file under mobile/android/.
As GeckoView isn't actually localised (see bug 1605358), this file
is not exposed to localisers.
A migration script is still included, as previous localisations of
the about:config view's strings are available from its Fennec days.
Running the script will fail in an m-c checkout bootstrapped for
desktop development; it's possible to hack around this by manually
setting the `l10n_toml` value in `python/l10n/test_fluent_migrations/fmt.py`.
Differential Revision: https://phabricator.services.mozilla.com/D155450
The synchronous DocumentL10n instance that's created here is not exposed on the root document, as that is the user-defined XML document. The localization root that's connected to it is in a closed shadow root.
This localization won't update on locale changes, but that matches what this view was previously doing.
Differential Revision: https://phabricator.services.mozilla.com/D156544
Since PowerShell is also available on Linux, checking for that is not
sufficient. We must first check if we're on Windows, and if we're not,
return early.
Differential Revision: https://phabricator.services.mozilla.com/D156602
Because the relevant SDK is not installed on the mac workers, we pull it
via fetches and adjust the plain build mozconfig as well as mozconfigs
for rusttest, grouping most things in build/macosx/mozconfig.common.
And because the SDK itself now has all the relevant headers, we don't
need the old check for system C++ headers (which also happens to have
outdated instructions)
Differential Revision: https://phabricator.services.mozilla.com/D156280
The strings from the translation.dtd and translation.properties files are all
merged into a single translationNotification.ftl file.
The string concatenation used in the original is maintained here, as DOM
Localization does not allow for using a <menulist> as a localized element.
Differential Revision: https://phabricator.services.mozilla.com/D155110
Except for the close-notification-message, all of the notification.dtd
strings are only used by popupnotification.js. Accordingly, the strings
are migrated to two different FTL files.
Differential Revision: https://phabricator.services.mozilla.com/D154890
Migrating the strings used by the edit dialogs also allows/requires for their migration elsewhere.
Some streamlining is applied to how autofillEditForms.js gets access to e.g. FormFillUtils methods, so that they are no longer routed via the XHTML files' script tags. The prior independence of this file from internal dependencies appears to have been in place to support its use as a part of the Payments API's UI, but that was dropped in bug 1721229.
The Fluent migration script included in this patch also covers changes from the immediately preceding patch.
The intl documentation change is a typo correction that was noticed while working on this patch.
Differential Revision: https://phabricator.services.mozilla.com/D155705
Migrating the strings used by the edit dialogs also allows/requires for their migration elsewhere.
Some streamlining is applied to how autofillEditForms.js gets access to e.g. FormFillUtils methods, so that they are no longer routed via the XHTML files' script tags. The prior independence of this file from internal dependencies appears to have been in place to support its use as a part of the Payments API's UI, but that was dropped in bug 1721229.
The Fluent migration script included in this patch also covers changes from the immediately preceding patch.
The intl documentation change is a typo correction that was noticed while working on this patch.
Depends on D155478
Differential Revision: https://phabricator.services.mozilla.com/D155705
What are we doing:
- Resolving a few bugs/user requests
Issues being addressed:
- Resolved issue where if the WPT_key.txt file is not available locally it does not affect running ./mach perftest-test
- Added section to WPT where we display the amount of tests we have remaining
- Altered the request_with_timeout function, to better handle requests
Differential Revision: https://phabricator.services.mozilla.com/D155268
I was not able to test this manually as it's a Windows-only component,
but it's at least somewhat covered by the tests in
browser/components/preferences/tests/browser_change_app_handler.js
which pass in CI.
Differential Revision: https://phabricator.services.mozilla.com/D155105
After the preceding change, the editMenuOverlay strings are only used by the styleeditor.
Therefore it makes sense to migrate them here specifically to its localization file.
Differential Revision: https://phabricator.services.mozilla.com/D155449
The upstream git-cinnabar repo no longer has the `git-cinnabar` scripts which
breaks the logic in mozboot. We no longer need to worry about making those files
executable and can simply use the download.py script to do the work. For the
current versions of download.py to work correctly, we need the git metadata to
exist, so use a --depth=1 clone instead.
Differential Revision: https://phabricator.services.mozilla.com/D155502
This should make handling errors more reliable in this situation.
Unfortunately I was unable to test this change, as on my local machine,
`./mach vendor rust` fails with an error even on a fresh checkout of
mozilla-central due to what appears to be an issue with loading
jsparagus sources.
Differential Revision: https://phabricator.services.mozilla.com/D155090
As the widget requires the individual fields' placeholder values to
be known during their build, the DOMLocalization instance used here
needs to have sync methods enabled. For the same reason, the
placeholder strings need to be separate messages, rather than
attributes on the same message as the corresponding label.
Differential Revision: https://phabricator.services.mozilla.com/D154448
This is regression by bug 1581971.
When using custom profile to run GVE via `./mach run --profile <directory>`,
we add "--profile" argument on `adb`. But, after landing bug 1581971, we
don't pass any profile arguments unfortunately.
So we should add it to use custom profile.
Also, This fixes that `./mach run --enable-fission` is broken. We don't need
`--profile` argument to run GVE with fission.
Differential Revision: https://phabricator.services.mozilla.com/D154772
The alert.properties file is not migrated here, as its contents are
also used by OS-specific alert notifications:
- widget/cocoa/OSXNotificationCenter.mm
- widget/windows/ToastNotificationHandler.cpp
Differential Revision: https://phabricator.services.mozilla.com/D154380
This migrates the remaining strings from both commonDialog.dtd and
dialogOverlay.dtd into a single new tabprompts.ftl file, as they are
only used by TabModalPrompt.
Differential Revision: https://phabricator.services.mozilla.com/D154423
This migrates the remaining strings from both commonDialog.dtd and
dialogOverlay.dtd into a single new tabprompts.ftl file, as they are
only used by TabModalPrompt.
Differential Revision: https://phabricator.services.mozilla.com/D154423
While here, square off the situation wrt compiler flags:
- target compiler flags used to be set conditionally but have been made
unconditional in bug 1409276, while leaving a hack around that adds
them under some conditions for host directories. We remove the hack
but keep the corresponding comment that is still relevant and should
be taken into account if target compiler flags are made conditional
later on.
- host compiler flags were excluded for host rust libraries, but that
was an oversight of bug 1409276, which should have applied the same
logic for host compilations.
- host compiler flags are actually potentially necessary for target rust
compilations because rust build scripts may build host C/C++ code
(that's the case for GLSL). We have no idea when that may happen, so
we always propagate them. config/makefiles/rust.mk then further
propagates the flags to cargo, but they have to be set in the backend
in the first place for that to happen.
Differential Revision: https://phabricator.services.mozilla.com/D154326
In order to allow rust-analyzer to be able to use the build script in
the mozbuild crate to discover the configuration information, this patch
adds new flags to the vscode config to tell rust-analyzer to invoke
cargo through `./mach cargo check`, and use the correct target directory
within the objdir rather than `$(topsrcdir)/target`.
Due to the virtual filesystem used by rust-analyzer not including files
in the object directory, this is not sufficient to get suggestions for
symbols from the included files, however it will accurately fetch
diagnostics upon save and run things like proc macros.
A new feature will likely need to be added to rust-analyzer to allow us
to specify additional paths to add to the source root for packages to
fix that issue.
Due to this change using `./mach cargo check`, rather than running it
independently, we don't run into issues caused by running `check`
against crates in the workspace which aren't being used, making the
diagnostics more useful.
An additional feature needed to be added to `./mach cargo check` to
allow specifying `--message-format=json`. I am open to suggestions for a
more elegant way to communicate this flag into the makefile.
Depends on D153269
Differential Revision: https://phabricator.services.mozilla.com/D153270
This converges Windows native notification behavior across all installers to use the COM notification server.
This also fixes an issue where interacting with an MSIX notification opened a new window with new tabs correlated to the toast notification launch arguments. MSIX by default calls the application sending a notification with the provided launch arugments, which was an problem as we use launch arguments in the COM server to reconstruct the origin of a notification.
Differential Revision: https://phabricator.services.mozilla.com/D153538
This will be used to replace the `LooseVersion` within `distutils`.
`StrictVersion` from `distutils` will need something else, as swapping
usages of `StrictVersion` with `LooseVersion` does not result in the
desired behavior.
Differential Revision: https://phabricator.services.mozilla.com/D151062
The baldrdash integration of Cranelift is agreed between SM and CL
to be the wrong shape. Our import of the code base is also old and
causes difficulties for us when upgrading some crates (see bug
1774829). We should remove it for now to unblock bug 1774829.
Differential Revision: https://phabricator.services.mozilla.com/D152806
fix if mercurial is not installed when running mach bootstrap, it will return None and mach will be confused if you are in a hg or git directory at all.
Differential Revision: https://phabricator.services.mozilla.com/D152310
The older versions don't have prebuilt wheels for python 3.9 and newer.
Unfortunately, the latest versions don't support python 3.7 and older,
so keep the older versions for those.
Differential Revision: https://phabricator.services.mozilla.com/D152246
- Removed `install_mercurial`, since it doesn't seem to be used.
- Rewrote `upgrade_mercurial` to act more like on Debian,
meaning it will prompt the user if Mercurial should be
installed via zypper or pip, and install via zypper if
non-interactive. Everything is then installed system-
wide.
- Moved `MERCURIAL_INSTALL_PROMPT` into `base.py`
- Added parantheses to `self.zypper_update()`.
Differential Revision: https://phabricator.services.mozilla.com/D152207
Test can be reenabled after the migration to Python 3.7+ (bug 1734402) because
the fixed Poetry version (1.2.0) has that as minimum requirement.
Differential Revision: https://phabricator.services.mozilla.com/D151913
This allows the profile service to handle `XRE_PROFILE_PATH`,
`--profile`, etc as normal before choosing a "default" background task
profile directory.
Differential Revision: https://phabricator.services.mozilla.com/D149918
Ideally, the code would handle things in a more general way that doesn't
require manually dealing with these lists, but this would require more
testing than there is time left before 102 releases.
While here, remove HOST_CPU_ARCH, which is always the same and thus
never appears in a condition.
This changes none of the generated moz.builds for the current
configuration (but changes the outcome when adding new configurations)
Differential Revision: https://phabricator.services.mozilla.com/D149850
The way the processor works currently is that it relies on two different
build backends, one of which produces json files for specific
configurations, and the other which produces moz.build files from the
aggregate of all those configs.
Each of these json files is huge, and we actually don't have enough to
support all the platforms we're supposed to be supporting. Adding more
files is not enticing.
Now that we've made the first step described above work in a single pass
on a single machine (as opposed to multiple passes on multiple machines
previously), we can actually merge both steps and avoid producing the
intermediate json files altogether. This will allow to add more
configurations without having to worry about the weight of those files.
And because this all doesn't need to depend on having the first step
hooked up in the build system, we make the whole an independent script
rather than a build backend.
Differential Revision: https://phabricator.services.mozilla.com/D149210
The way the processor works currently is that it relies on two different
build backends, one of which produces json files for specific
configurations, and the other which produces moz.build files from the
aggregate of all those configs.
Each of these json files is huge, and we actually don't have enough to
support all the platforms we're supposed to be supporting. Adding more
files is not enticing.
Now that we've made the first step described above work in a single pass
on a single machine (as opposed to multiple passes on multiple machines
previously), we can actually merge both steps and avoid producing the
intermediate json files altogether. This will allow to add more
configurations without having to worry about the weight of those files.
And because this all doesn't need to depend on having the first step
hooked up in the build system, we make the whole an independent script
rather than a build backend.
Differential Revision: https://phabricator.services.mozilla.com/D149210
As we're shortly going to stop producing the intermediate json files,
we want the fixups to happen in the GN processor.
Ideally, we'd move them all, but cleaning up -isysroot is more involved,
while we won't need it once we don't use intermediate json files, so we
leave the -isysroot cleanup in fixup_json.py for now.
While here, `gn_out["targets"][target_fullname]` doesn't need to be set
on every iteration of the loop.
Differential Revision: https://phabricator.services.mozilla.com/D149209
The current script requires to be run on 4 different host platforms each
of which would handle a subset of a total of 32 mozconfigs. That is not
sustainable, and there are already missing configs that break tier-3
platforms.
This replaces the current setup with one that handles all platforms in
one go, although we still keep the internal sequence of GcConfigGen ->
fixup_json -> GnMozbuildWriter.
The downside is that because this relies on the upstream webrtc build
system supporting cross-compilation, and that it actively rejects some
configurations, we need some local hacks to make it work on Linux and
Mac, but for now, we have to leave out Windows, which requires more
work.
For some reason, that removes some duplicated include directories in the
json files, which moves things a little in one moz.build file.
We also remove the mozconfigs we don't use anymore.
Differential Revision: https://phabricator.services.mozilla.com/D149205
The way the processor works currently is that it relies on two different
build backends, one of which produces json files for specific
configurations, and the other which produces moz.build files from the
aggregate of all those configs.
Each of these json files is huge, and we actually don't have enough to
support all the platforms we're supposed to be supporting. Adding more
files is not enticing.
Now that we've made the first step described above work in a single pass
on a single machine (as opposed to multiple passes on multiple machines
previously), we can actually merge both steps and avoid producing the
intermediate json files altogether. This will allow to add more
configurations without having to worry about the weight of those files.
And because this all doesn't need to depend on having the first step
hooked up in the build system, we make the whole an independent script
rather than a build backend.
Differential Revision: https://phabricator.services.mozilla.com/D149210
As we're shortly going to stop producing the intermediate json files,
we want the fixups to happen in the GN processor.
Ideally, we'd move them all, but cleaning up -isysroot is more involved,
while we won't need it once we don't use intermediate json files, so we
leave the -isysroot cleanup in fixup_json.py for now.
While here, `gn_out["targets"][target_fullname]` doesn't need to be set
on every iteration of the loop.
Differential Revision: https://phabricator.services.mozilla.com/D149209
The current script requires to be run on 4 different host platforms each
of which would handle a subset of a total of 32 mozconfigs. That is not
sustainable, and there are already missing configs that break tier-3
platforms.
This replaces the current setup with one that handles all platforms in
one go, although we still keep the internal sequence of GcConfigGen ->
fixup_json -> GnMozbuildWriter.
The downside is that because this relies on the upstream webrtc build
system supporting cross-compilation, and that it actively rejects some
configurations, we need some local hacks to make it work on Linux and
Mac, but for now, we have to leave out Windows, which requires more
work.
For some reason, that removes some duplicated include directories in the
json files, which moves things a little in one moz.build file.
We also remove the mozconfigs we don't use anymore.
Differential Revision: https://phabricator.services.mozilla.com/D149205
A week ago we received a notification that we had a test that the WPT chrome tests were perma failing on [[ https://bugzilla.mozilla.org/show_bug.cgi?id=1773621 | bugzilla ]]
After going through the fail logs I realized it was because of website "panda.tv" directing to a unable to connect page message, after some digging it was not returning proper data because panda.tv has not been a company since March 2019(bankruptcy filing), why this only is causing an issue now I believe is because of some kind of update from WPT as I can see a noticeable UI difference on the test results page from before and after the failures started.
My resolution was to remove Panda.tv from our test list and that seems to have resolved the issue.
I also updated the error message to display which website is causing the issue so that if this happens again I don't need to go through each and every webpagetest result to know which of the 40 websites are having an issue.
Differential Revision: https://phabricator.services.mozilla.com/D149642
Including glean_parser 6.1.1
Two important things in there:
* glean_parser: [data-review] Include extra keys' names and descriptions in data review template
* Glean: Derive `serde::{Deserialize, Serialize}` on `Lifetime` and `CommonMetricData`
Differential Revision: https://phabricator.services.mozilla.com/D149381
I also added `%USERPROFILE%/.mozbuild` to the exclusion list and updated the windows_build docs to reflect the changes made.
Differential Revision: https://phabricator.services.mozilla.com/D149199
When `./mach bootstrap` is called with the default mozconfig file,
verify the content matches the selected build target, and if not,
show a warning and ask whether to overwrite or not.
Differential Revision: https://phabricator.services.mozilla.com/D146384
The patch aims to improve the `_should_install()` method for installing browsertime in mozperftest.
Here, the same approach used in `testing/raptor/mach_commands.py` is used to address potential issues (e.g. KeyError)
that one may encounter when trying to install from the `package.json` through this approach.
Differential Revision: https://phabricator.services.mozilla.com/D148565
This next patch in the series utilizes the same login-logic in Mozperftest and makes it available to the `pageload_test` method so that we can now automate the logging into of accounts during perftest recordings.
Additional logic is also added to account for if the site requires login, if we are running on CI or locally (and if on CI, accounting for the SCM level), and removal of the verbose flags so secrets do not leak.
Differential Revision: https://phabricator.services.mozilla.com/D147775
When `./mach bootstrap` is called with the default mozconfig file,
verify the content matches the selected build target, and if not,
show a warning and ask whether to overwrite or not.
Differential Revision: https://phabricator.services.mozilla.com/D146384
The cargo-vet toolchain is auto-bootstrapped and setup for things to
work properly. We modify `mach vendor rust` to invoke `mach cargo vet`
instead of doing its own setup, but in a underhanded way to work around
bug 1772453.
Differential Revision: https://phabricator.services.mozilla.com/D148218
