This creates a new service that stores precisely two bits per RP, IDP, and account ID tuple:
has it been used before and is it able to be logged out.
It does so with the additional constraints of respecting private browsing's clear on last session and in-memory storage constraints and being a participant in the Clear Storage Service.
Tests are here. Coverage isn't perfect, but they cover most of the service.
Differential Revision: https://phabricator.services.mozilla.com/D162124
This creates a new service that stores precisely two bits per RP, IDP, and account ID tuple:
has it been used before and is it able to be logged out.
It does so with the additional constraints of respecting private browsing's clear on last session and in-memory storage constraints and being a participant in the Clear Storage Service.
Tests are here. Coverage isn't perfect, but they cover most of the service.
Differential Revision: https://phabricator.services.mozilla.com/D162124
This creates a new service that stores precisely two bits per RP, IDP, and account ID tuple:
has it been used before and is it able to be logged out.
It does so with the additional constraints of respecting private browsing's clear on last session and in-memory storage constraints and being a participant in the Clear Storage Service.
Tests are here. Coverage isn't perfect, but they cover most of the service.
Differential Revision: https://phabricator.services.mozilla.com/D162124
Ideally we would use the window mediator to just find new browser windows that
are in the process of opening but while we can find the windows they just appear
as about:blank with no way to verify that they are browser windows.
This just takes the straightforward approach of forcing code that opens browser
windows to register them with the BrowserWindowTracker and provides a simple
shared API for opening browser windows that does this.
Differential Revision: https://phabricator.services.mozilla.com/D161076
Ideally we would use the window mediator to just find new browser windows that
are in the process of opening but while we can find the windows they just appear
as about:blank with no way to verify that they are browser windows.
This just takes the straightforward approach of forcing code that opens browser
windows to register them with the BrowserWindowTracker and provides a simple
shared API for opening browser windows that does this.
Differential Revision: https://phabricator.services.mozilla.com/D161076
We had a number of tests that assumed that when adding a browser_action without
specifying the default_area, that the button would enter the navbar. The previous
patch in this series changes that assumption when the Unified Extensions UI is
enabled.
Instead of updating all of these tests to add additional steps to move the
browser_action's out to the navbar after adding them, I've gone ahead and
updated them to default their browser_action's to the navbar instead.
Differential Revision: https://phabricator.services.mozilla.com/D161721
We had a number of tests that assumed that when adding a browser_action without
specifying the default_area, that the button would enter the navbar. The previous
patch in this series changes that assumption when the Unified Extensions UI is
enabled.
Instead of updating all of these tests to add additional steps to move the
browser_action's out to the navbar after adding them, I've gone ahead and
updated them to default their browser_action's to the navbar instead.
Differential Revision: https://phabricator.services.mozilla.com/D161721
Thunderbird now has an identical copy of AppUpdater.jsm in its repository. Moving it into
toolkit will make ongoing maintenance easier.
Differential Revision: https://phabricator.services.mozilla.com/D161718
We want to encourage extension developers to use `browser_specific_settings` instead of `applications`, which will be unsupported in Manifest Version 3+. This patch makes sure test manifests in m-c won't cause any issues in the future.
Depends on D160541
Differential Revision: https://phabricator.services.mozilla.com/D160668
At the moment, launching with `-private-window` (which we now do more easily with `private_browsing.exe` and the associated shortcut) when private browsing is disabled will open a private-looking window that is not private...which is very misleading.
This includes:
* Shortcut creation (which will end up with private shortcuts that open non-private windows)
* Setting AUMID and window/taskbar icons
The latter is handled with a guard in the two places we do it (nsWindow.cpp & BrowserContentHandler.jsm). Ideally, no caller would ever request a private window when private browsing is disabled...but I don't think that's a realistic possibility.
I also noticed we're doing some unnecessary work in the jump list builder when private browsing is disabled, so I fixed that.
I don't think this is reasonably testable in automation (ultimately, AUMID and icons are attributes of the Windows API objects, and we don't have the scaffolding to retrieve those in tests) -- but I'd be happy to be wrong about this.
Differential Revision: https://phabricator.services.mozilla.com/D160568
This ended up being a nearly total rewrite of AppUpdater, but I think that the changes are worth it.
The flow is much more linear which makes it easier to follow and reason about.
The API is made much more formal by making most methods and members private.
Many potential race conditions have been removed.
Many more potential errors thrown can now be caught by the try/catch that wraps `AppUpdater.check`, causing those errors to show the "Internal Error" message rather than causing the update interface to just freeze.
Cancelling an in-progress update check works more reliably.
This patch does not change AppUpdater consumers to accomodate these changes. That will come later in the patch stack.
Differential Revision: https://phabricator.services.mozilla.com/D159298
