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
We currently support stack walking everywhere, and when it fails, we fall back
to leaf stacks. The leaf option is a bit confusing in how it works, and doesn't
provide much value.
Differential Revision: https://phabricator.services.mozilla.com/D153695
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
Ensure extensions can manage tabs and sessions that include tabs from other extensions. The parent
patch to this introduces cross-extension access validation. However that breaks this specific use case
that we need to continue supporting. This patch modifies three extension apis, tab.create/update and
windows.create to allow the creation of extension tabs which cannot be otherwise accessed.
Differential Revision: https://phabricator.services.mozilla.com/D151766
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
The biggest set of APIs from ns[T]StringObsolete which are still heavily used
are the string searching APIs. It appears the intention was for these to be
replaced by the `FindInReadable` APIs, however that doesn't appear to have
happened.
In addition, the APIs have some quirks around their handling of mixed character
widths. These APIs generally supported both narrow strings and the native
string type, probably because char16_t string literals weren't available until
c++11. Finally they also used easy-to-confuse unlabeled boolean and integer
optional arguments to control behaviour.
These patches do the following major changes to the searching APIs:
1. The ASCII case-insensitive search method was split out as
LowerCaseFindASCII, rather than using a boolean. This should be less
error-prone and more explicit, and allows the method to continue to use
narrow string literals for all string types (as only ASCII is supported).
2. The other [R]Find methods were restricted to only support arguments with
matching character types. I considered adding a FindASCII method which would
use narrow string literals for both wide and narrow strings but it would've
been the same amount of work as changing all of the literals to unicode
literals.
This ends up being the bulk of the changes in the patch.
3. All find methods were re-implemented using std::basic_string_view's find
algorithm or stl algorithms to reduce code complexity, and avoid the need to
carry around the logic from nsStringObsolete.cpp.
4. The implementations were moved to nsTStringRepr.cpp.
5. An overload of Find was added to try to catch callers which previously
called `Find(..., false)` or `Find(..., true)` to set case-sensitivity, due
to booleans normally implicitly coercing to `index_type`. This should
probably be removed at some point, but may be useful during the transition.
Differential Revision: https://phabricator.services.mozilla.com/D148300
Ensure extensions can manage tabs and sessions that include tabs from other extensions. The parent
patch to this introduces cross-extension access validation. However that breaks this specific use case
that we need to continue supporting. This patch modifies three extension apis, tab.create/update and
windows.create to allow the creation of extension tabs which cannot be otherwise accessed.
Differential Revision: https://phabricator.services.mozilla.com/D151766
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
equal throws immediately, so if it fails you get some follow-on
failures because the test didn't clean up that make it confusing
to figure out what actually failed. This patch fixes that by using
registerCleanupFunction to remove the extension, and waits to
do the check until after contentPage has been closed.
Differential Revision: https://phabricator.services.mozilla.com/D152419
