This patch includes:
- changes to WebRequest.jsm to always default to only merge the CSP headers returned by MV3 extensions
- changes to the test_ext_webRequest_mergecsp.js xpcshell test to cover the behavior expected
with MV3 extensions and combinations of both MV2 and MV3 extensions changing CSP headers
for the same intercepted web request.
For MV3 extensions we would prefer a more explicit and predictable way for the
extensions to be allowed to replace the CSP header, instead of keeping the same
unpredictable and implicit one that we currently support for MV2 extensions.
Differential Revision: https://phabricator.services.mozilla.com/D154983
This patch won't actually build, because a few bits of code are used
for both nsIFactory::createInstance and static components, and static
components are not fixed until the next patch.
The first place is nsLoadGroupConstructor, which uses an nsIFactory
macro to create a static component constructor. (This could be worked
around by expanding the macro to the state before this patch.)
The other issue is that nsAppShellConstructor is used in an nsIFactory
on OSX, but as a static component on all other platforms. This could
be worked around by wrapping nsAppShellConstructor in an adaptor that
passes in the extra null argument to nsAppShellConstructor.
Differential Revision: https://phabricator.services.mozilla.com/D146456
Before this patch, nsISiteSecurityService APIs took "flags" parameters that
differentiated private contexts from not private contexts. However, these
parameters were redundant with respect to origin attributes, which led to some
confusion for consumers of these APIs. This patch removes these parameters in
favor of using origin attributes.
Differential Revision: https://phabricator.services.mozilla.com/D142901
The event listener callback wasn't bound to this, so the access to `activityErrorMap`
was failing.
This patch slightly modifies the event listener so we use a fat arrow function,
as well as adding the `once` option, since we were removing the event listener
the first time the callback was called.
Differential Revision: https://phabricator.services.mozilla.com/D138894
We add the new content policy here, but leave the behavior as TYPE_OTHER, so
we can verify that the new test fails before the fix is applied.
Differential Revision: https://phabricator.services.mozilla.com/D124965
Automatically generated path that adds flag `REQUIRES_UNIFIED_BUILD = True` to `moz.build`
when the module governed by the build config file is not buildable outside on the unified environment.
This needs to be done in order to have a hybrid build system that adds the possibility of combing
unified build components with ones that are built outside of the unified eco system.
Differential Revision: https://phabricator.services.mozilla.com/D122345
This patch fixes the intermittent failures being triggered by test_ext_webrequest_auth.html by making sure that
the "http-on-modify-request" observers added by the test tasks part of this test file are going to ignore any http
request that isn't related to the mochi.test url that is expected to trigger the authentication dialog.
With the previous version of the chrome script executed by these two test tasks, there was a chance that the observer
would be setting the mocked nsIAuthPromptProvider/nsIauthPromp2 notification callback on the wrong channel, if
the http channel was also related to the mochi.test host. After that the observer was removed and it would not be
setting the notificationCallbacks on the channel that was meant to set it on (and that would make the testcase to
trigger the actual authentication prompt that can be seen in the failure screenshots).
As part of this patch we are also reverting the additional debugging logs added in a previous patch attached to
this issue.
Differential Revision: https://phabricator.services.mozilla.com/D119880
As for document.fonts, I don't think we intentionally meant to apply
CSP to User/UserAgent fonts. The document certainly has no authority
to block those from loading. (We already have a separate principal
for these which is further evidence that this was unintentional
and we can use the same bit (mUseOriginPrincipal) to avoid CSP.)
Differential Revision: https://phabricator.services.mozilla.com/D111695
The public key pinning implementation is much less complex than the HSTS
implementation, and only needs a small subset of the parameters of the latter.
Furthermore, the information it relies on is static, and so is safe to access
from content processes. This patch separates the two implementations, thus
simplifying both of them and avoiding some unnecessary IPC calls in the
process.
Differential Revision: https://phabricator.services.mozilla.com/D117096
As for document.fonts, I don't think we intentionally meant to apply
CSP to User/UserAgent fonts. The document certainly has no authority
to block those from loading. (We already have a separate principal
for these which is further evidence that this was unintentional
and we can use the same bit (mUseOriginPrincipal) to avoid CSP.)
Differential Revision: https://phabricator.services.mozilla.com/D111695
