object-src used to be required because it controls plugins, and we did
not want to load unsafe sources as plugins. With NPAPI plugin support
having been dropped a long time ago, this reason no longer exist.
The requirement for "secure" object-src CSP directive meant that
extensions had to specify a boilerplate object-src if they wanted to
modify script-src.
This patch removes the object-src requirement from extension CSP,
which simplifies the usage and learning curve of CSP usage in
extensions.
With this change, extensions can now load "unsafe" (remote) content
via `<embed>` and `<object>` tags. This relaxation does not reduce
the security because this was already possible with `<iframe>` tags.
Differential Revision: https://phabricator.services.mozilla.com/D156747
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
It seems that the "browser-lastwindow-close-granted" observer is not entirely reliable about notifying when the last window was closed. Instead we will rely on "domwindowclosed" and checking if that was the last window, which seems to be more reliable.
Differential Revision: https://phabricator.services.mozilla.com/D151859
The failures triggered after the changes introduced in this test from Bug 1784292 and tracked by orangefactor
are all triggered from the test case named `test_blockedInstallDomain_with_unified_extensions`:
- in that test case we are using a new chrome window (because the test case covers the behaviors expected when
the unified extension button have been enabled by flipping the related pref) and the new chrome
window is closed shortly after calling BrowserTestUtils.openNewForegroundTab.
- By opening and quickly closing a new chrome window, of all the tests in that test file,
`test_blockedInstallDomain_with_unified_extensions` is the only one that have a pretty
good chance to trigger this kind of failure.
- the failure is triggered when the chrome window has been already closed by the time all the promises that
BrowserTestUtils.openNewForegroundTab is internally waiting on (see the lines linked below) are settled,
and that triggers the failure due to an uncaught rejection triggered as a side-effect of trying to access
tabbrowser.ownerGlobal.windowGlobalChild for a chrome window that is already gone:
- https://searchfox.org/mozilla-central/rev/380fc5571b039fd453b45bbb64ed13146fe9b066/testing/mochitest/BrowserTestUtils/BrowserTestUtils.jsm#278-279
The attached patch just adds an await on the call to BrowserTestUtils.openNewForegroundTab, which prevents
the intermittent failure from being triggered.
As a side note (either as an alternative approach to the one currently in this patch or indipendently from
fixing this specific intermittent):
it seems worth confirming if we could be changing BrowserTestUtils.openNewForegroundTab to expect
the possibility that the chrome window have been closed and just omit the innerWindowId in the
profile marker if collected too late to be able to retrieve the innerWindowId.
Differential Revision: https://phabricator.services.mozilla.com/D155876
This patch is the result of `mach esmify --convert toolkit/mozapps/extensions/internal/GMPProvider.jsm`.
Callsites were fixed manually, as well as occasional references in comments.
Differential Revision: https://phabricator.services.mozilla.com/D155832
This was oversight. In background tasks, I took some care to provide
the snapshot of the default profile's targeting state to the Firefox
Messaging System, but it also needs to be provided to Nimbus to filter
experiments directly.
For expedience, I provide an extra targeting context object to
`ExperimentManager.onStartup`.
The targeting contexts for Nimbus proper and Firefox Messaging System
are somewhat independent; that's why the triggering context remains in
the invocation of `sendTriggerMessage`.
Depends on D154308
Differential Revision: https://phabricator.services.mozilla.com/D154309
I tested this as much as I could locally -- hence the `dump`
workaround -- but I have no particular suggestion for how to test this
in automation. Even triggering the targeting snapshotting during
shutdown requires the timers and shutdown process to line up in a way
that's not trivial to guarantee.
Differential Revision: https://phabricator.services.mozilla.com/D154285
This converges Windows native notification behavior across all installers to use the COM notification server.
This also fixes an issue where interacting with an MSIX notification opened a new window with new tabs correlated to the toast notification launch arguments. MSIX by default calls the application sending a notification with the provided launch arugments, which was an problem as we use launch arguments in the COM server to reconstruct the origin of a notification.
Differential Revision: https://phabricator.services.mozilla.com/D153538
Rob Wu
Butkovits Atila
Neil Deakin
Mark Banner
Norisz Fay
Marian-Vasile Laza
Max Christian Pohle
Itiel
Nick Alexander
Kirk
Katherine Patenio
Sarah Clements
Paul Zuehlcke
Luca Greco
nchevobbe
Amy Churchwell
Dana Keeler
Sandor Molnar
William Durand
Dão Gottwald
Sean Pedigo
Geoff Lankow
Mike Kaply
Shane Caraveo
Nicholas Rishel