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
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
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
This error message provides extra information to developers so they know why the access was denied
(e.g. for public etld, remote subframes, ...).
Differential Revision: https://phabricator.services.mozilla.com/D159246
`nsIEditor.transactionManager` is used only for some simple purposes, however,
`nsIEditor` exposes the rich API. That makes it harder to maintain internal
code around transactions. Instead, `nsIEditor` exposes only simple and
necessary APIs.
This patch creates a new API to clear undo/redo history and make the users in
mozilla-central use it instead of using `nsITransactionManager.clear()`.
Differential Revision: https://phabricator.services.mozilla.com/D158336
The code is slightly cleaned up to not construct identifiers by concatenating strings, and to avoid using the requestTypes array when determining the prompt contents.
A few messages are moved to and from browser.ftl to group them better, though all of the "WebRTC Pop-up notifications" messages could also be moved from there to webrtcIndicator.ftl, which is now also included by browser.xhtml.
The message `webrtc-allow-share-audio-capture-unsafe-delegation` is added, as it appears to have been missed previously -- it's referred to in code, but the message itself was not defined.
Differential Revision: https://phabricator.services.mozilla.com/D158762
