backup-settings changes:
- adds a new button in the Backup section of about:preferences / about:settings
- shows the turn on dialog after pressing the button
Turn on dialog behaviour (implemented):
- pressing the cancel will close the dialog
- pressing the confirm button will set the pref browser.backup.scheduled.enabled=true and close the dialog
- pressing the passwords checkbox will show more options
Turn on dialog behaviour (not implemented):
- requiring a password for the backup (see Bug 1895981)
- modifying the save location and showing a file picker (see Bug 1895943)
Other changes:
- tests for backup-settings and the turn on dialog
- Storybook template for the turn on dialog
Lo-fi Figma designs: https://www.figma.com/design/vNbX4c0ws0L1qr0mxpKvsW/Fx-Backup?node-id=147-4558&t=PYLY0QMN1n8GR9vW-0
Differential Revision: https://phabricator.services.mozilla.com/D209769
Adds logic that ensures that the SelectTranslationsPanel
cannot be resized off the bottom edge of the screen when
click-and-dragging the vertical textarea resizer within
the panel.
Depends on D209396
Differential Revision: https://phabricator.services.mozilla.com/D209178
Determines if the SelectTranslationsPanel was positioned before
opening such that the bottom corner of the panel is the anchor
point. This causes the text-area resizer to grow the panel
upward even though the user is dragging downward, so we should
disable resizing in this case.
Differential Revision: https://phabricator.services.mozilla.com/D209396
The earlier patches in this stack (a) made it possible to await on the stub to complete and (b) ensured that the update system initiates properly regardless of when and if the update service stub is invoked. This allows us to remove explict stub invocations in some cases and to have the await on the results in others.
Differential Revision: https://phabricator.services.mozilla.com/D209129
A number of changes are made as part of this patch:
- A consistent way of initializing update is created. This is automatically run when methods that need it are invoked.
- The "post-update-processing" notification has been removed. Post update processing is now done through the new `nsIApplicationUpdateService.init` or `nsIApplicationUpdateService.internal.postUpdateProcessing`.
- Post update processing no longer waits for the sessionstore-windows-restored observer service notification
- Post update processing is no longer invoked only when the `update.status` file exists. It is now run unconditionally.
- Explicitly initialize before we potentially clean up updates from the update UI.
Note that the update service stub and a few consumers of it ought to be able to wait for post update processing to be done but they currently do not. That will be done later in this patch stack when we rework the stub.
Differential Revision: https://phabricator.services.mozilla.com/D209126
Aside from tests (which will be in the next patch in the stack), this specifically leaves two instances of readyUpdate unchanged - the one in BrowserContentHandler's `getArgs` and the one in UpdatePing's `_getActiveUpdate`. In both of these cases what is actually wanted is the update that was just installed. It's only because of the (fairly arbitrary) order that things are started up in that `readyUpdate` still happens to contain this value when these things run. Later in this patch stack we will add something more appropriate for this. But in the meantime, it doesn't make sense to convert functions to be asynchronous that will not ultimately need to be asynchronous.
Differential Revision: https://phabricator.services.mozilla.com/D209115
I want the initialization function that I'm going to add later in the patch stack to be asynchronous, so the update entry points should be asynchronous functions.
Differential Revision: https://phabricator.services.mozilla.com/D209109
enrollWithRollout skipped all enrollment logic in ExperimentManager.enroll by
calling ExperimentStore.addEnrollment directly. This prevents prefs being set
by Nimbus correctly when enrolling. enrollWithFeatureConfig already supports
enrolling as a rollout, so all uses of enrollWithRollout have been replaced.
Differential Revision: https://phabricator.services.mozilla.com/D209936
enrollWithRollout skipped all enrollment logic in ExperimentManager.enroll by
calling ExperimentStore.addEnrollment directly. This prevents prefs being set
by Nimbus correctly when enrolling. enrollWithFeatureConfig already supports
enrolling as a rollout, so all uses of enrollWithRollout have been replaced.
Differential Revision: https://phabricator.services.mozilla.com/D209936
The earlier patches in this stack (a) made it possible to await on the stub to complete and (b) ensured that the update system initiates properly regardless of when and if the update service stub is invoked. This allows us to remove explict stub invocations in some cases and to have the await on the results in others.
Differential Revision: https://phabricator.services.mozilla.com/D209129
A number of changes are made as part of this patch:
- A consistent way of initializing update is created. This is automatically run when methods that need it are invoked.
- The "post-update-processing" notification has been removed. Post update processing is now done through the new `nsIApplicationUpdateService.init` or `nsIApplicationUpdateService.internal.postUpdateProcessing`.
- Post update processing no longer waits for the sessionstore-windows-restored observer service notification
- Post update processing is no longer invoked only when the `update.status` file exists. It is now run unconditionally.
- Explicitly initialize before we potentially clean up updates from the update UI.
Note that the update service stub and a few consumers of it ought to be able to wait for post update processing to be done but they currently do not. That will be done later in this patch stack when we rework the stub.
Differential Revision: https://phabricator.services.mozilla.com/D209126
Aside from tests (which will be in the next patch in the stack), this specifically leaves two instances of readyUpdate unchanged - the one in BrowserContentHandler's `getArgs` and the one in UpdatePing's `_getActiveUpdate`. In both of these cases what is actually wanted is the update that was just installed. It's only because of the (fairly arbitrary) order that things are started up in that `readyUpdate` still happens to contain this value when these things run. Later in this patch stack we will add something more appropriate for this. But in the meantime, it doesn't make sense to convert functions to be asynchronous that will not ultimately need to be asynchronous.
Differential Revision: https://phabricator.services.mozilla.com/D209115
I want the initialization function that I'm going to add later in the patch stack to be asynchronous, so the update entry points should be asynchronous functions.
Differential Revision: https://phabricator.services.mozilla.com/D209109
This patch creates a new context menu for the revamped sidebar, including existing
options for managing extensions. We should be able to build off the `onSidebarPopupShowing`
function to customize what we want to show based on what sidebar item we right click.
Differential Revision: https://phabricator.services.mozilla.com/D208951
