I suspect this was causing more than just the issue reported -- on Linux (and presumably Mac) this function ended up throwing an exception, which seems like it could interfere with handling of more than just `-private-window`.
Differential Revision: https://phabricator.services.mozilla.com/D158165
This allows to connect a `backgroundTaskMessage` popping a toast
notification with a given `name` through to a re-engagement with
Firefox.
Differential Revision: https://phabricator.services.mozilla.com/D156637
We'll be defaulting Felt Privacy features to enabled, and allowing them to be disabled by Nimbus (primarily for a holdback study).
Differential Revision: https://phabricator.services.mozilla.com/D153275
When the notification server callback is executed by the Windows
notification system, it invokes Firefox with additional command line
parameters, most importantly the Windows-specific notification
"Windows tag".
If no appropriate Firefox is running, the command line will be
processed, the provided Windows tag will be inspected (and seen to not
be registered with this running Firefox instance) and a "launch URL"
stored as part of the Windows notification itself opened (if one is
provided).
If an appropriate Firefox is running, the remoting protocol will
forward this command line to the running instance. If the instance
recognizes the provided `--notification-windowsTag`, the command line
will be ignored. When the notification server exits, Windows will
fallback to the Windows 8.1 style notification callbacks registered
for this Windows tag and the existing (non notification server)
behaviour will occur.
In fact, the server therefore waits for a Windows tag-specific system
event to be signalled by the invoked Firefox (or a sibling process).
If we were to return `S_OK` from the notification server immediately,
and a running Firefox process would handle the notification via
Windows 8.1-style notification callbacks, then Windows would fall back
to those callbacks. The invoked callbacks unregister themselves upon
completion, often before the launched Firefox has an opportunity to
process the command line. By waiting for this system event, we allow
the invoked Firefox to process the command line while its own
notification callbacks are registered and therefore recognize that its
callbacks will handle the notification.
Differential Revision: https://phabricator.services.mozilla.com/D154468
When the notification server callback is executed by the Windows
notification system, it invokes Firefox with additional command line
parameters, most importantly the Windows-specific notification
"Windows tag".
If no appropriate Firefox is running, the command line will be
processed, the provided Windows tag will be inspected (and seen to not
be registered with this running Firefox instance) and a "launch URL"
stored as part of the Windows notification itself opened (if one is
provided).
If an appropriate Firefox is running, the remoting protocol will
forward this command line to the running instance. If the instance
recognizes the provided `--notification-windowsTag`, the command line
will be ignored. When the notification server exits, Windows will
fallback to the Windows 8.1 style notification callbacks registered
for this Windows tag and the existing (non notification server)
behaviour will occur.
In fact, the server therefore waits for a Windows tag-specific system
event to be signalled by the invoked Firefox (or a sibling process).
If we were to return `S_OK` from the notification server immediately,
and a running Firefox process would handle the notification via
Windows 8.1-style notification callbacks, then Windows would fall back
to those callbacks. The invoked callbacks unregister themselves upon
completion, often before the launched Firefox has an opportunity to
process the command line. By waiting for this system event, we allow
the invoked Firefox to process the command line while its own
notification callbacks are registered and therefore recognize that its
callbacks will handle the notification.
Differential Revision: https://phabricator.services.mozilla.com/D154468
We'll be defaulting Felt Privacy features to enabled, and allowing them to be disabled by Nimbus (primarily for a holdback study).
Differential Revision: https://phabricator.services.mozilla.com/D153275
We will be defaulting Felt Privacy features to enabled, and allowing them to be disabled by Nimbus (primarily for a holdback study).
Differential Revision: https://phabricator.services.mozilla.com/D153275
`browser.privacySegmentation.enabled` is going to be set when users opt into Felt Privacy. When I originally wrote some of this code I naively used it to pref things on, on the assumption that there would never be a situation where it would be `true` before 106 (when we remove the pref-off for this work).
However, we want to run an experiment with pinning private browsing to the taskbar ahead of 106. To avoid any possibility of accidentally opting users into Felt Privacy without their consent, let's use a distinct pref for turning these features off for now. This pref will disappear in the 106 cycle, as none of this code needs to be behind one at that point - so I don't _think_ this needs to go in `firefox.js`.
Differential Revision: https://phabricator.services.mozilla.com/D151065
This is subject to the same issue as an earlier patch in this series -- the icon will be wrong briefly at first launch, before the code in `BrowserContentHandler.jsm` replaces the default icon with the correct one.
Differential Revision: https://phabricator.services.mozilla.com/D138601
This is done differently depending on whether the Private Browsing window is the initial one, or if it's a new window from a running application. In the former case, we're still not setting it up early enough -- the window will initially show up in one icon, and then switch to the other one after we've adjusted the AUMID.
Regardless, the fact that we're doing it for every new window appears to mean that other places that require it (such as GeckoChildProcessHost.cpp) will Do The Right Thing (because they'll pull the cached version that `GetAppUserModelID` finds).
This behind a pref for now both because of the issue noted above, as well as the fact that we're waiting on finalized branding for this.
Differential Revision: https://phabricator.services.mozilla.com/D138194
This is subject to the same issue as an earlier patch in this series -- the icon will be wrong briefly at first launch, before the code in `BrowserContentHandler.jsm` replaces the default icon with the correct one.
Differential Revision: https://phabricator.services.mozilla.com/D138601
This is done differently depending on whether the Private Browsing window is the initial one, or if it's a new window from a running application. In the former case, we're still not setting it up early enough -- the window will initially show up in one icon, and then switch to the other one after we've adjusted the AUMID.
Regardless, the fact that we're doing it for every new window appears to mean that other places that require it (such as GeckoChildProcessHost.cpp) will Do The Right Thing (because they'll pull the cached version that `GetAppUserModelID` finds).
This behind a pref for now both because of the issue noted above, as well as the fact that we're waiting on finalized branding for this.
Differential Revision: https://phabricator.services.mozilla.com/D138194
This is subject to the same issue as an earlier patch in this series -- the icon will be wrong briefly at first launch, before the code in `BrowserContentHandler.jsm` replaces the default icon with the correct one.
Differential Revision: https://phabricator.services.mozilla.com/D138601
This is done differently depending on whether the Private Browsing window is the initial one, or if it's a new window from a running application. In the former case, we're still not setting it up early enough -- the window will initially show up in one icon, and then switch to the other one after we've adjusted the AUMID.
Regardless, the fact that we're doing it for every new window appears to mean that other places that require it (such as GeckoChildProcessHost.cpp) will Do The Right Thing (because they'll pull the cached version that `GetAppUserModelID` finds).
This behind a pref for now both because of the issue noted above, as well as the fact that we're waiting on finalized branding for this.
Differential Revision: https://phabricator.services.mozilla.com/D138194
This is subject to the same issue as an earlier patch in this series -- the icon will be wrong briefly at first launch, before the code in `BrowserContentHandler.jsm` replaces the default icon with the correct one.
Differential Revision: https://phabricator.services.mozilla.com/D138601
This is done differently depending on whether the Private Browsing window is the initial one, or if it's a new window from a running application. In the former case, we're still not setting it up early enough -- the window will initially show up in one icon, and then switch to the other one after we've adjusted the AUMID.
Regardless, the fact that we're doing it for every new window appears to mean that other places that require it (such as GeckoChildProcessHost.cpp) will Do The Right Thing (because they'll pull the cached version that `GetAppUserModelID` finds).
This behind a pref for now both because of the issue noted above, as well as the fact that we're waiting on finalized branding for this.
Differential Revision: https://phabricator.services.mozilla.com/D138194
The `-osint` flag is used as the signal that Windows is invoking
Firefox to handle a file type or protocol. The `-osint` flag was
introduced in order to mitigate security breaches due to poor argument
quoting (by consumers invoking Firefox); to use it for this new
purpose, it must be preserved for downstream consumers to react to.
Alternately, some marker of the flag could be maintained. Since the
flag needs to transit through the launcher process, I've elected to
simply not strip it as we validate command lines, and to accommodate
it further downstream. (It looks like Thunderbird already
accommodates `-osint`: see
https://searchfox.org/comm-central/rev/3e8f926de9ea09945b237177eb6d489c70318f0e/mail/components/MessengerContentHandler.jsm#568.)
The telemetry in this patch achieves two purposes. The first is to
count the number of times Firefox is invoked to handle a registered
file type or protocol: for this, a new keyed uint scalar was added.
File types start with a ".", just like on Windows; protocols
(equivalently, the schemes used to identify them) do not start with a
".".
The second is to identify times when Firefox is launched (i.e., it was
not already running) to handle a registered file type or protocol.
This generalizes the existing `os.environment.launch_method`,
introducing `os.environment.launched_to_handle` and
`os.environment.invoked_to_handle` string scalars, which record the
file type or protocol.
The command line state `STATE_INITIAL_LAUNCH` is used to discriminate
launching from invoking.
Differential Revision: https://phabricator.services.mozilla.com/D132288
This will allow starting Firefox in the background, and on Windows will allow
closing the last browser window without killing the main process. There is no
plan for actually using this by default in Firefox proper, but it's needed for
some explorations.
There's more to this work that we'll need - this is just the first step. For
instance, we'll need a real way to actually kill firefox on Windows other than
through the task manager (we'll be putting something in the system tray to
allow this.)
The patch wasn't particularly large, so I didn't split out the rename of
MOZ_APP_SILENT_START to MOZ_APP_SILENT_RESTART - let me know if you'd like me
to do that though and I can.
Differential Revision: https://phabricator.services.mozilla.com/D124249
Modify the command line handler such that it does not open any window on the initial application launch when the MOZ_APP_SILENT_RESTART env value is set.
Depends on D123019
Differential Revision: https://phabricator.services.mozilla.com/D123020
Add new NimbusFeatures.upgradeDialog with fallback enabled pref. Remember if the browser just did a major uprgade and check other conditions for showing before other default browser messages.
Differential Revision: https://phabricator.services.mozilla.com/D111041
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
Raw Cr.ERROR don't get stack information, same as throwing JS literals instead
of `new Error()`s.
This was done automatically with a new eslint rule that will be introduced in
the next commit. One instance of a raw Cr.ERROR was not replaced since it is
used in a test that specifically checks the preservation of raw Cr values in
XPCJS. The rule will be disabled for that instance.
Differential Revision: https://phabricator.services.mozilla.com/D28073
