OriginControls setAlwaysOn and setWhenClicked methods should be taking into account manifest and granted host permissions
Categories
(WebExtensions :: General, defect, P2)
Tracking
(firefox131 fixed)
| Tracking | Status | |
|---|---|---|
| firefox131 | --- | fixed |
People
(Reporter: rpl, Assigned: rpl)
References
Details
(Whiteboard: [addons-jira])
Attachments
(1 file)
While working on the patch for Bug 1851083 I was testing out the behaviors using a small MV3 test extension which had in the manifest an activeTab permission and a content script matching “https://developer.mozilla.org/*”, the manifest looked like the following:
{
"manifest_version": 3,
"content_scripts": [{
"matches": ["https://developer.mozilla.org/*"],
"js": ["content.js"]
}],
"permissions": ["activeTab", "scripting"],
...
}
While testing out behaviors around the origin controls menu items I noticed that after having manually revoked that host permissions from about:addons and then clicked on the “Always allow on developer.mozilla.org” origin control menu item then in the about:addons permissions view for that test extension there were now two host permissions:
- The one derived from the content script matching (“https://developer.mozilla.org/*”) that I manually revoked from about:addons
- And a new separate one added by the origin control menu item “Always allow on developer.mozilla.org (://developer.mozilla.org/), which does not actually match nor subsumed by the one derived from the content script matching
A kind of opposite issue can also be triggered by the opposite STR:
while the “https://developer.mozilla.org/*” permission is granted (which is implicitly done as part of installing the mv3 extensions since Firefox 127), clicking on the “Only When Clicked” does not revoke that host permission, because we try to remove the broader ://developer.mozilla.org/ (which is not actually granted) instead, while the one that was derived from the content script and was already granted (and allows access to the current website) stays granted (but we still notify a permissions.onRemoved event for a permission that was never actually granted).
Based on these observed behaviors it looks like these two methods should instead take into account:
- what optional permissions the extension declared in the manifest when granting new host permissions through OriginControls.setAlwaysOn
- and the host permissions actually granted when revoking host permissions through OriginControls.setWhenClicked
This bugzilla ticket is meant to track discussing and agreeing about the expected behavior of the origin controls feature under this scenario.
I’ll attach a patch that drafts the approach described above so that we can then continue discussing and getting to an agreement on the behaviors of these OriginControls methods directly on the code related to this logic in phabricator.
| Assignee | ||
Comment 1•1 year ago
|
||
Depends on D215038
Comment 2•1 year ago
|
||
This issue happens because the UI usually shows the domain part of the "host permission" / "origin permission", which does not leave room for a scheme, whereas internally we do account for them. We encountered the same issue in permissions.request vs the permissions in the add-on manager UI.
bug 1856383 is another example of the UI getting confused when a more specific http/https scheme is present instead of the wildcard scheme in *://*/*.
| Assignee | ||
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Comment 4•1 year ago
|
||
| bugherder | ||
Description
•