They cause differences between the x86-64 and arm64 halves of a
universal build, and are not necessary in release builds.
As a side effect, we now end up normalizing Info.plist contents.
Differential Revision: https://phabricator.services.mozilla.com/D96015
Since python creates little-endian utf-16 consistently whether
cross-compiling from Linux or compiling natively on macOS, we could
write a small script that essentially replaces iconv. On the other hand,
we're also doing some manual preprocessing on the InfoPlist.strings.in
files, and we might as well use the preprocessor for that.
So, we augment the preprocessor to allow an explicit output encoding
other than utf-8, and use the preprocessor instead of `sed | iconv`.
Differential Revision: https://phabricator.services.mozilla.com/D96013
We scan for addon changes twice, once early in startup (usually with no scanning) and once after ui startup. We hold on to the startup data, and during both scans we restore that data into the addon location instances. The problem here is if we install a builtin in-between these scans. The new data from the install would get overwitten by the old data. In some cases this caused addons to disappear (e.g. old data has incorrect path). Other issues covered here is that we would never remove addon data for builtins removed from the system, and we would additionally mark builtins as sideloads, which caused other side effects (particularly with search addons) where we would not load the addon, but fortunately the search service later re-installes them.
Differential Revision: https://phabricator.services.mozilla.com/D95422
This method only is async in order to allow callers to wait for a process switch
triggered by the call to `loadURI` to be finished before resolving. With
DocumentChannel, we should never trigger a process switch eagerly like this
again, so we don't need any of the async behaviour here anymore.
This part is largely mechanical changes to tests, removing the `await` calls on
`loadURI`, and a follow-up part will remove the actual async logic from
`BrowserTestUtils.loadURI`.
Differential Revision: https://phabricator.services.mozilla.com/D94641
We scan for addon changes twice, once early in startup (usually with no scanning) and once after ui startup. We hold on to the startup data, and during both scans we restore that data into the addon location instances. The problem here is if we install a builtin in-between these scans. The new data from the install would get overwitten by the old data. In some cases this caused addons to disappear (e.g. old data has incorrect path). Other issues covered here is that we would never remove addon data for builtins removed from the system, and we would additionally mark builtins as sideloads, which caused other side effects (particularly with search addons) where we would not load the addon, but fortunately the search service later re-installes them.
Differential Revision: https://phabricator.services.mozilla.com/D95422
- Added a new permission dialog shown when the caller does not have permission to open a protocol
- Updated the appChooser dialog for the new UX
- Updated and moved l10n strings to fluent (fluent migration in the following patch)
Differential Revision: https://phabricator.services.mozilla.com/D94149
- Added pref to toggle permission feature
- Updated ContentDispatchChooser to check for permission and manage a multi dialog flow.
Differential Revision: https://phabricator.services.mozilla.com/D92945
- Added a new permission dialog shown when the caller does not have permission to open a protocol
- Updated the appChooser dialog for the new UX
- Updated and moved l10n strings to fluent (fluent migration in the following patch)
Differential Revision: https://phabricator.services.mozilla.com/D94149
- Added pref to toggle permission feature
- Updated ContentDispatchChooser to check for permission and manage a multi dialog flow.
Differential Revision: https://phabricator.services.mozilla.com/D92945
This essentially cribs the equivalent installer conditional elevation.
I elected to guard this behind /S (silent) because it's not obvious to
me that unelevated users will see identical behaviour when not
elevating.
Differential Revision: https://phabricator.services.mozilla.com/D76254
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
While making other changes, I took a second look at some code I wrote in Bug 1668096, and found a few little mistakes. This patch fixes them up.
Depends on D94191
Differential Revision: https://phabricator.services.mozilla.com/D94192
TelemetryEnvironment.jsm's EnvironmentAddonBuilder has a shutdown
blocker that depends on the addons database to have been loaded.
There are two calls to asyncLoadDB() in XPIProvider.jsm that are
supposed to activate the load. Neither of them work:
- XPIProvider calls asyncLoadDB() during quitApplicationGranted.
But "quit-application-granted" is not always triggered, as seen in:
https://bugzilla.mozilla.org/show_bug.cgi?id=1601678#c12
- XPIProvider.shutdown() calls asyncLoadDB().
But shutdown() is only called when TelemetryEnvironment's blocker has
been released. So this is never reached. More details in:
https://bugzilla.mozilla.org/show_bug.cgi?id=1601678#c7
To fix the deadlock, asyncLoadDB() is called from profile-before-change,
which is the same phase as the blocker of EnvironmentAddonBuilder.
The two existing calls to asyncLoadDB() mentioned above are obsolete and
have been removed.
---
After the removal of asyncLoadDB() from XPIProvider.shutdown(), the
test_ext_persistent_events.js test started to fail. This is because the
test sends the "sessionstore-windows-restored" notification, for which
XPIProvider has a handler that calls asyncLoadDB(), without awaiting
the result.
Since XPIProvider.shutdown() doesn't await the DB load any more, it is
possible for the DB to be unloaded while being used. This only happens
in tests, because the construction with the TelemetryEnvironment ensures
that the addons database has fully loaded before shutdown() is called.
To resolve this test-only issue, AddonTestUtils.promiseShutdownManager()
has been updated to explicitly wait for the pending _dbPromise if any.
Differential Revision: https://phabricator.services.mozilla.com/D91388
My patch for bug 1665195 included a REBOOTOK flag because I wanted to make
sure the UpdateLogs directory would get deleted even if doing so failed at the
moment. What I didn't realize is that the RmDir instruction will set the reboot
flag if removing the directory fails for any reason whatsoever, even if it's
just because the directory wasn't empty, in which case rebooting wouldn't help.
For some reason I thought there was a check for that condition, but having now
had a look in the NSIS source, there is not.
There's no easy way to check for ourselves whether the directory is empty or
not, so to avoid a spurious reboot prompt from either the installer or the
uninstaller, this patch just gives up on the REBOOTOK flag.
Differential Revision: https://phabricator.services.mozilla.com/D93860
Updated tests to wait a moment for the update badge. The badge is added on a timeout, so it may not be there when we first look.
Some tests actually already use this mechanism:
browser_doorhanger_bc_downloadOptIn_bgWin.js
browser_doorhanger_bc_downloadAutoFailures_bgWin.js
I'm not sure why it wasn't used consistently, but it seems to fix the intermittent failures with browser_aboutDialog_fc_downloadAuto.js to add the mechanism.
Differential Revision: https://phabricator.services.mozilla.com/D93837
The `clobber` targets are superseded by `mach clobber`, so we don't need them for any reason. The `clean` target is meant to get you to a post-`configure` state, but it doesn't really work, and if it's necessary for you to be in that state for some reason you can just clobber and re-`configure`, so it doesn't seem worth it to get it working again. Instead, delete all of them. Also delete `everything` which is not useful when `clobber` doesn't exist.
Differential Revision: https://phabricator.services.mozilla.com/D93514
This patch does not make the necessary replacement in tests. Those changes will be made in a later patch in this stack.
Some additional, related changes are also made in this patch:
cleanupActiveUpdate is being replaced with cleanupDownloadingUpdate and cleanupReadyUpdate. The two new functions currently do very similar things, but separating them will allow us to have each function clean up the right update, once we fully support more than one update per session.
The old mechanism to add something to the update history was for it to be assigned to activeUpdate, and then to assign null to activeUpdate. We now need to assign active updates to be null without adding them to the history. As an example, we need to set downloadingUpdate to null when the download completes, but it shouldn't be added to the history at that point. To address this, an explicit addUpdateToHistory function has been added, and assigning null to either active update variable no longer moves the update to the update history.
Differential Revision: https://phabricator.services.mozilla.com/D92289
Tim Nguyen
Mark Hammond
Mike Hommey
smolnar
Shane Caraveo
pbz
Razvan Maries
Nika Layzell
Ricky Stewart
Dorel Luca
Nick Alexander
Bogdan Tara
Itiel
Gijs Kruitbosch
Adam Gashlin
Kirk Steuber
Marco Bonardo
Rob Wu
Molly Howell
Sebastian Hengst
Sylvestre Ledru
Anny G
Kris Maglione