Move activeTabpermission information to a new concept page - #45263
Move activeTabpermission information to a new concept page#45263rebloor wants to merge 7 commits into
activeTabpermission information to a new concept page#45263Conversation
github-actions
Bot
added
Content:Firefox
| - selecting an extension's context menu item. | ||
| - activating a keyboard shortcut defined by the extension with the {{WebExtAPIRef("commands")}} API. | ||
| - clicking a button on a page bundled with the extension. | ||
| - clicking an extension suggestion in the address bar (omnibox) (from Firefox 142). |
There was a problem hiding this comment.
For each of these actions, can we list the event that is triggered, and from each event also point to the activeTab documentation?
|
|
||
| The point at which access ends varies by browser [browser_compatibility](#browser_compatibility). | ||
|
|
||
| ## Example |
There was a problem hiding this comment.
Do we have samples from our repo that we can link in this article? If not then I can submit a PR to attach an example with the tab context menu, as an example.
There was a problem hiding this comment.
Table of all examples requesting activetab permission added.
There was a problem hiding this comment.
I was wondering why the macro wasn't used, which auto-generates the listing of examples based on examples.json in the repo. Is it because activeTab is a permission and not fitting in the javascript_apis definition?
I suppose that a manual listing is better than no listing for now.
There was a problem hiding this comment.
@Rob--W yes, as I understand it, example.json only provides for listing JavaScript APIs using javascript_apis. This appears to be supported by the changes suggested in Add JSON schema and validation for examples.json#641. I presume that when this was originally set up, the assumption was that there would be a one-to-one between API and permission (where needed).
Co-authored-by: Rob Wu <rob@robwu.nl>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
|
|
||
| The point at which access ends varies by browser [browser_compatibility](#browser_compatibility). | ||
|
|
||
| ## Example |
There was a problem hiding this comment.
I was wondering why the macro wasn't used, which auto-generates the listing of examples based on examples.json in the repo. Is it because activeTab is a permission and not fitting in the javascript_apis definition?
I suppose that a manual listing is better than no listing for now.
| <tbody> | ||
| <tr> | ||
| <td> | ||
| <a href="https://github.com/mdn/webextensions-examples/apply-css/" |
There was a problem hiding this comment.
Fixed in Fix links to example extensions
| > | ||
| </td> | ||
| <td> | ||
| A context menu click on a link unlocks the page so the link can be |
| ### Other differences | ||
|
|
||
| - **Permission prompts**: Firefox and Chrome grant an extension's requested host permissions on installation, so `activeTab` avoids an install-time warning. Safari, by contrast, defaults host permissions to "ask", and prompts the user the first time the extension tries to access a site, offering **Allow for One Day** or **Always Allow**. Using `activeTab` avoids this prompt, as Safari treats the user's interaction with the extension as the grant. | ||
| - **Manifest V2 and V3**: `activeTab` works the same way in both manifest versions in all browsers. In Manifest V3, the {{WebExtAPIRef("scripting")}} API replaces {{WebExtAPIRef("tabs.executeScript()")}} and {{WebExtAPIRef("tabs.insertCSS()")}}, and the `"scripting"` permission is needed alongside `activeTab`. |
There was a problem hiding this comment.
Actually... Firefox's MV2 was more permissive than MV3 with regards to activeTab, see https://bugzilla.mozilla.org/show_bug.cgi?id=1839200#c3
|
|
||
| The listener is passed the command's name. This matches the name given to the command in its [manifest.json entry](/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/commands). | ||
|
|
||
| If the extension has the [`activeTab` permission](/en-US/docs/Mozilla/Add-ons/WebExtensions/activeTab_permission), activating a command's keyboard shortcut is a user action that grants it temporary access to the active tab. |
There was a problem hiding this comment.
I like that the link here is formatted with "permission" inside the brackets. But across the PR I see that "activeTab" is the only label of the link, with "permission" after the link (not linkified). Unless you have a particular reason otherwise, could you put "permission" next to activeTab (so that both terms become the link), across the whole PR?
|
|
||
| ## Browser compatibility | ||
|
|
||
| Firefox, Safari, and Chromium-based browsers, including Chrome and Edge, support `activeTab`. However, when it's granted, what it enables, and when it's revoked vary. |
There was a problem hiding this comment.
Not sure where to mention it, but the way that Firefox grants activeTab differs from Chrome:
- Firefox grants access to the active tab only.
- Chrome grants access to host permissions derived from the tab's URL.
Chrome's logic unlocks potentially more access than Firefox:
- another tab with the same origin can be scripted in Chrome, not in Firefox.
- an extension script (e.g. background script, popup panel's script, etc) can make a cross-origin request to the URL in Chrome, not in Firefox.
- the cookies API requires host permissions to access cookies for specific domains. Chrome allows that, Firefox does not.
- this list is not exhaustive.
Safari matches Firefox's behavior, see this discussion on activeTab behavior and also Safari's mentions: https://github.com/w3c/webextensions/blob/main/_minutes/2026-04-09-london-f2f.md#pr-799-add-browserpermissionscanaccess-proposal
There was a problem hiding this comment.
Done. I've added it under the capabilities granted section. I'm not sure whether the discussion link was simply FYI, but I haven't included it: I couldn't see that it would quickly provide a reader with any obvious or helpful additional information.
| | Capability | Chrome | Firefox | Safari | | ||
| | ----------------------------------------------------------------------------------- | ------------------------------------ | ----------------------------------------------------- | -------------- | | ||
| | Programmatic script and stylesheet injection | Yes | Yes | Yes | | ||
| | Privileged {{WebExtAPIRef("tabs.Tab")}} properties (`url`, `title`, `favIconUrl`) | Yes | Yes | Yes | |
There was a problem hiding this comment.
From @Rob--W Privileged to sensitive. Please check across the patch to see if you need to do it in more places.
And maybe also include without requiring the "tabs" permission for clarity?
And also make sure to mention the activeTab permission in the three fields at the tabs.Tab type: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/tabs/Tab#faviconurl
Co-authored-by: Rob Wu <rob@robwu.nl>
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
| | Capability | Chrome | Firefox | Safari | | ||
| | ----------------------------------------------------------------------------------- | ------------------------------------ | ----------------------------------------------------- | -------------- | | ||
| | Programmatic script and stylesheet injection | Yes | Yes | Yes | | ||
| | Sensitive {{WebExtAPIRef("tabs.Tab")}} properties (`url`, `title`, `favIconUrl`) | Yes | Yes | Yes | |
There was a problem hiding this comment.
[mdn-linter] reported by reviewdog 🐶
| | Sensitive {{WebExtAPIRef("tabs.Tab")}} properties (`url`, `title`, `favIconUrl`) | Yes | Yes | Yes | | |
| | Sensitive {{WebExtAPIRef("tabs.Tab")}} properties (`url`, `title`, `favIconUrl`) | Yes | Yes | Yes | |
3 participants
Description
This change moves all information about the
activeTabpermission to a new concepts page (placed after the content and background script articles). It also adds an example illustrating how to useactiveTab. All references toactiveTabshould now link back to the concept page.Motivation
This change increases the visibility of information about
activeTab, given its significance to web extension development.Additional details
browser_specific_settings.geckoadd-on ID anddata_collection_permissions.activeTabwhen activating a context menu item from the tab bar is no longer mentioned in the body text (given the change occurred 8 years ago); however, it is detailed in the tables identifying differences between the browsers.Related issues and pull requests
Fiyes #40942