Closed Bug 1905146 Opened 1 year ago Closed 1 year ago

OriginControls setAlwaysOn and setWhenClicked methods should be taking into account manifest and granted host permissions

Categories

(WebExtensions :: General, defect, P2)

defect

Tracking

(firefox131 fixed)

RESOLVED FIXED
131 Branch
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.

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 *://*/*.

See Also: → 1856383
Severity: -- → S3
Priority: -- → P2
Whiteboard: [addons-jira]
Assignee: nobody → lgreco
Attachment #9410015 - Attachment description: WIP: Bug 1905146 - OriginControls setAlwaysOn and setWhenClicked methods should be taking into account manifest and granted host permissions → Bug 1905146 - OriginControls setAlwaysOn and setWhenClicked methods should be taking into account manifest and granted host permissions. r?robwu,zombie
Status: NEW → ASSIGNED
Pushed by imoraru@mozilla.com: https://hg.mozilla.org/mozilla-central/rev/3cb36a616270 OriginControls setAlwaysOn and setWhenClicked methods should be taking into account manifest and granted host permissions. r=robwu,zombie
Status: ASSIGNED → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → 131 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: