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
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 patch includes only the subset of D145687 changes related to the reworked JSONSchema data, plus some minor changes to Schemas.jsm to take the new
JSONSchema type ("PrivilegedPermissions") and the new custom JSONSchema keyword (the boolean "privileged" property used to identify manifest fields
only allowed in privileged extensions).
Besides the changes to the schema data, this patch is not expected to introduce any difference in behavior and so it could also land on its own
if needed (and the rest of the changes landed separately).
Differential Revision: https://phabricator.services.mozilla.com/D146800
This patch includes only the subset of D145687 changes related to the reworked JSONSchema data, plus some minor changes to Schemas.jsm to take the new
JSONSchema type ("PrivilegedPermissions") and the new custom JSONSchema keyword (the boolean "privileged" property used to identify manifest fields
only allowed in privileged extensions).
Besides the changes to the schema data, this patch is not expected to introduce any difference in behavior and so it could also land on its own
if needed (and the rest of the changes landed separately).
Differential Revision: https://phabricator.services.mozilla.com/D146800
- Remove unsupported tabs API definitions that are gone in MV3.
- Mark content script APIs (superseded by scripting APIs) as MV2-only.
- Re-enable extension.getBackgroundPage in MV2 since it makes sense with
event pages, and we enabled runtime.getBackgroundPage in bug 1759308.
- Add tests that verify API availability in MV3.
Differential Revision: https://phabricator.services.mozilla.com/D143721
This allows themes to override our light / dark theme heuristics if they
choose to, so that we don't have to complicate the heuristics too much.
This is specially useful for themes with images, where the image might
be "light", but still have enough contrast with light text. A good
example is the theme mentioned in bug 1749837 comment 0.
The semantics are:
* color_scheme: If set, overrides the general "toolbar theme" (so
window and context menu appearance and so on), otherwise we fall back
to heuristics.
* content_color_scheme: If set, overrides the color scheme for the
content area. Otherwise we fall back to color_scheme if present, or
heuristics otherwise.
One thing that I didn't include was a sort of "system" option, which
might be useful to say "this theme is neutral, and works both for light
and dark themes". Let me know if you think that's a must-have, otherwise
I think it's probably worth deferring to a follow-up if it's needed at
all.
Differential Revision: https://phabricator.services.mozilla.com/D136354
