This patch refactors the existing nativeMessaging tests, by introducing
a shared helper to test bad nativeMessaging hosts. It also introduces a
hook to the test helper to allow the test to easily manipulate the
generated native messaging manifest to intentionally trigger the error
conditions. These are used to add test coverage for scenarios that were
previously not covered.
test_forward_slashes_in_path_works is the regression test for the linked
bug.
Differential Revision: https://phabricator.services.mozilla.com/D157984
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
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 offers the Rule type and updateSessionRules and
getSessionRules to register rules. The actual evaluation of rules and
most of the associated validation is not part of this patch.
Differential Revision: https://phabricator.services.mozilla.com/D154801
This test seems to fail frequently on Linux without Fission, and on Android,
when the parent controlled navigation pref is enabled, so disable the test
there. We don't really support non-Fission builds anyways, and apparently
containers aren't supported on Android.
Differential Revision: https://phabricator.services.mozilla.com/D154288
Restrict the DNR permissions to MV3 to allow the add-ons linter to
easily flag the use of the not-yet-supported DNR permission, until
we do actually enable the feature.
Since the full DNR namespace is gated on this permission, this
effectively means that in order to use the API, not only the
extensions.dnr.enabled pref needs to be set, but also the
extensions.manifestV3.enabled pref + using manifest_version: 3..
Differential Revision: https://phabricator.services.mozilla.com/D153458
This patch adds the minimum necessary to register the
declarativeNetRequest API and its permissions, behind prefs.
Tests have been added/updated to verify that the permissions and API
access are enforced correctly (effectiveness of preferences, API
visibility, permission warnings).
Before landing this, we need to register the permission warning in
Android-Components too, as mentioned in the bug (i.e. bug 1671453).
Differential Revision: https://phabricator.services.mozilla.com/D152503
Restrict the DNR permissions to MV3 to allow the add-ons linter to
easily flag the use of the not-yet-supported DNR permission, until
we do actually enable the feature.
Since the full DNR namespace is gated on this permission, this
effectively means that in order to use the API, not only the
extensions.dnr.enabled pref needs to be set, but also the
extensions.manifestV3.enabled pref + using manifest_version: 3..
Differential Revision: https://phabricator.services.mozilla.com/D153458
This patch adds the minimum necessary to register the
declarativeNetRequest API and its permissions, behind prefs.
Tests have been added/updated to verify that the permissions and API
access are enforced correctly (effectiveness of preferences, API
visibility, permission warnings).
Before landing this, we need to register the permission warning in
Android-Components too, as mentioned in the bug (i.e. bug 1671453).
Differential Revision: https://phabricator.services.mozilla.com/D152503
This adds a content script that sends a test message that runs
after the user scripts to ensure that the user scripts have
finished running. Otherwise, we can end up checking the value
of textContent before the script runs. This happens frequently
with both Fission enabled and with parent-controlled navigation.
This has to be done in a content script because sendMessage is
not available in a user script.
Based on the test name and the comments that added this test,
it should have been testing userScripts.register instead of
contentScripts.register, so I fixed that.
I also fixed a few references in text to contentScript.register
that should be contentScripts.register.
Differential Revision: https://phabricator.services.mozilla.com/D153293
This patch adds WebIDL bindings for the `scripting` namespace.
Note that `scripting.executeScript()` is excluded for now.
Differential Revision: https://phabricator.services.mozilla.com/D141463
This patch includes the following tweaks to the new test cases as introduced from Bug 1770696:
- Added an explicit `await waitForSubprocessExit();` to the two new test cases which are starting
a NativeApplication as part of the test case, to make sure to wait for the subprocess to have
been fully exited, otherwise that triggers a failure on windows 10 because the files that should
be removed when the test task is exiting would still be in use (and trying to remove them fails
only on the windows platform)
- Reworked the NativeApp used by the testSendNativeMessage test task to don't wrongly assume the
NativeApp handling all the messages sent to be the same one even if one is still running to
handle a delayed message pending a reply:
- Each sendNativeMessage call will be spawning its own NativeApp instance and so the test native
app is now resorting to a `time.sleep(...)` call to delay replying to any message received,
to give some time for the test case to cover the behavior expected while a native message is
still pending a reply.
- Added Some stderr logs to the NativeApp, to make it easier to see at which point of
the test case the NativeApp is being started, replying to a message and terminated, along
with including the process pid to more easily determine if the NativeApp instance is still
the one we expect to be running and replying to the native messages received.
Differential Revision: https://phabricator.services.mozilla.com/D152292
