Closed Bug 1851083 Opened 11 months ago Closed 14 days ago

Manifest V3 extensions with activeTab/tabs permission require user interaction not previously required, showing blue dot on desktop and no indicator on Android

Categories

(WebExtensions :: General, defect, P3)

defect

Tracking

(firefox-esr128 fixed, firefox117 wontfix, firefox118 wontfix, firefox119 wontfix, firefox120 wontfix, firefox121 wontfix, firefox128 wontfix, firefox129 verified)

VERIFIED FIXED
129 Branch
Tracking Status
firefox-esr128 --- fixed
firefox117 --- wontfix
firefox118 --- wontfix
firefox119 --- wontfix
firefox120 --- wontfix
firefox121 --- wontfix
firefox128 --- wontfix
firefox129 --- verified

People

(Reporter: robert, Assigned: rpl)

References

(Blocks 2 open bugs)

Details

(Whiteboard: [addons-jira])

Attachments

(1 file, 1 obsolete file)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/116.0

Steps to reproduce:

  1. Develop an new Manifest V3 low privileges extension using only 'activeTab' permission as recommended on MDN:

"permissions": [
"activeTab",
"scripting"
]

  1. Loading the extension in Firefox.

Actual results:

For every website there is a blue dot asking for permissions on the extensions menu button and on the extension button. This is annoying, the idea of the "activeTab" permission is that an extension can do things on a website with running an extension action, without annoying the user with permissions prompts or like this, the blue dot.

Expected results:

An extension with simple permissions like this, should not be asking for permissions with the blue dot on every web page. These kind of dots are annoying because it notifies the user something is new or needs attention, and on this case it isn't true. The extension action will run only when the button is activated

Reverting to a Manifest V2 extension with the same permission doesn't show the blue dot.

The Bugbug bot thinks this bug should belong to the 'WebExtensions::Untriaged' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Product: Firefox → WebExtensions

Hello,

I reproduced the issue on the latest Nightly (119.0a1/20230903210251), Beta (118.0b4/20230903180219) and Release (117.0/20230824132758) under Windows 10 x64 and macOS 11.3.1.

I will set the issue to NEW, however, in my opinion the display of the attention dot on each page is useful and correctly implemented. The user should be notified that an extension needs explicit permission to run, then let the user decide if the user shall allow it or not and not grant the permission automatically. On the other hand, if the dot is not displayed and an extension needs permission to run, the user might think the extension does not work since the permission was not granted and the user was not notified that he should do so.

I will NeedInfo one of our developers to ask for a second opinion on this.

Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(lgreco)

I can't talk for every user but I find these dots annoying for things that don't requires my immediate attention. As an example, It is like the red dot on Edge to use a Microsoft account, the dot is placed there because a lot of people will get annoyed and just make an account to get rid of it.

As I explained on the original report, If I switch the manifest to version 2, there is no request for permissions at install time, no blue dot on every site and even I can access protected information like tab.url.

If the blue dot was important, it should have been important on V2 manifest too.

As a side note, a V3 extension with only optional permissions:

  "optional_permissions": [
    "*://*/*",
    "activeTab",
    "scripting"
  ]

In order to request permissions for each site if needed at runtime, shows the blue dot for every site. The idea of them being optional is that the extension can do some operation without these permissions and later ask for them if required.

Flags: needinfo?(lgreco) → needinfo?(tomica)

I think it's worth noting that this issue occurs if the extension only requests the "activeTab" permission. To reproduce it, add the following text to a file named "manifest.json" and load it as a temporary extension.

{
  "name": "Blue dot",
  "version": "0.1",
  "manifest_version": 3,
  "permissions": [ "activeTab" ],
  "action": {}
}

According to MDN:

If an extension has the activeTab permission, then when the user interacts with the extension, the extension is granted extra privileges for the active tab only.

https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/permissions#activetab_permission

The MDN article doesn't indicate that the user must grant permission for every website in order for the extension to make use of tab-related functionality that the "activeTab" permission would allow.

This issue also affects our addon, which has the tabs permission, making it virtually useless.

Firefox for Android has the same issue, and the situation is worse: the addon’s script injection doesn’t work until you open the UI (popup on desktop) through the Add-ons menu, and there is no indication like a blue dot.

Blocks: manifest-v3
Component: Untriaged → General
Version: Firefox 116 → unspecified

It was also reported in the Firefox support as a very confusing behavior. The affected add-on was https://addons.mozilla.org/de/firefox/addon/duplicate_tab/ which uses the activeTab permission.

I agree that the blue dot is useful if there is something actionable for the user, for example if the user has to grant a permission. But that's not the case for the activeTab permission. It's confusing because the user can't do anything and the menu still shows the blue dot, without any chance to get rid of it. And so the menu draws attention to itself all the time, even though there is nothing for the user to do. The text in the add-ons menu that the add-on requires a permission does not help to reduce the confusion at all, as the user thinks they have to do something and that's not true.

@Alex Cornestean:

The user should be notified that an extension needs explicit permission to run, then let the user decide if the user shall allow it or not and not grant the permission automatically.

Agreed. But that's not the case for the activeTab permission. The activeTab permission just works, and there is nothing the user can grant or forbid.

I’ve quickly analyzed some extensions listed on the spreadsheet linked from this Add-ons Blog post and realized that most extensions still use MV2. We gotta back out our MV3 migration as it’s not a blocker for the Android support. 😔

Blocks: 1711787
Severity: -- → S3
Priority: -- → P3

The user should be notified that an extension needs explicit permission to run, then let the user decide if the user shall allow it or not and not grant the permission automatically. On the other hand, if the dot is not displayed and an extension needs permission to run, the user might think the extension does not work since the permission was not granted and the user was not notified that he should do so.

I wonder if there should be a way for an extension to indicate that it wants to work? In the case of my extension [1], it's not supposed to actually do something until the user clicks the icon. So the user is asked to pay attention to the icon for every page they visit, even though they'll usually don't actually want/need to pay attention to it. What makes it worse is that the only way to get rid of the notification icon, is to actually click the extension button, which activates it - which in most cases, they don't actually want to do! See [2] for a report logged by a user of my extension who was confused by this behaviour.

[1] https://addons.mozilla.org/addon/obfuscator/

[2] https://gitlab.com/vincenttunru/obfuscate/-/issues/14

My users of Trufflepiggy - Context Search are also super confused that a green circle appears below my extension icon (Firefox 121).

Trufflepiggy - Context Search also uses the activeTab permission. The only chance to get rid of it is to also request the <all_urls> permission which is truly unnecessary for a context menu extension. At least I never had issues since 2017 with the MV2 version of it.
Since the MV3 upgrade my user support inbox is so overfilled with questions about that behaviour that I might update host_permissions to <all_urls> just to get rid of these requests.

https://addons.mozilla.org/firefox/addon/trufflepiggy-context-search/

With a P3 priority I don't see this bug getting fixed any time soon (or ever :D), so it's best to switch back to MV2.
There really is no good reason to use MV3 in Firefox just yet, especially since MV2 supports many of the new MV3 introduced API so compatibility is great.
You can ask more questions here:

Perhaps we can implement optional_host_permissions (bug 1766026) and use that as a signal to opt out of the UI that notifies the user of the need to grant host permissions.

See Also: → 1766026

The dot can be hidden with this CSS:

#unified-extensions-button[attention] > .toolbarbutton-icon,
.unified-extensions-item[attention] > .unified-extensions-item-action-button.toolbarbutton-1 > .toolbarbutton-badge-stack {
  background-image: none !important;
}

The dot can be hidden with this CSS:

This is not a solution since it removes the dot in every case, and that's not what this ticket is about. If a permission actually has to be granted, the dot is a useful indicator and should be shown. But if the activeTab permission causes that the indicator is always there, it decreases the usefulness of the indicator.

I think the summary needs to be clarified.

Summary: Manifest V3 extensions with low privilege activeTab shows annoying blue dot for all websites → Manifest V3 extensions with activeTab/tabs permission require user interaction not previously required, showing blue dot on desktop and no indicator on Android

I forgot to say: We use Svelte + Vite to build our extension. I have created a Vite plugin that downgrades MV3 to MV2 for Firefox during packaging. If you’re interested, here’s the code:

https://github.com/videomark/videomark/blob/master/vite.config.js#L42
https://github.com/videomark/videomark/blob/master/vite-plugin-package-extension.js

The Refined GitHub extension also hit this bug recently: https://github.com/refined-github/refined-github/issues/7477

I believe the issue here is that ManifestV3 is underspecified: some extensions only work on specific sites, others are general and can work anywhere but the spec doesn't allow the authors to specify this. The extensions in the former category will explicitly list all domains in the hostPermisions and so it makes no sense for the browser UI to show a dot to grant it access to further domains.
One such extension is Refined GitHub: the request of the activeTab permission is intended to restrict its actions, but with the prerequisite that the tab domain be one of the 2 that are listed in the manifest, not to signal that the extension can work anywhere. Perhaps the browser can use that signal do disable the extension when the user switches away from the tab.

In the presence of this spec

"permissions": [ "activeTab" ],
"host_permissions": [
  "https://github.com/*",
  "https://api.github.com/*"
],

the Firefox devs chose to interpret that as meaning that the extension could also work on other sites, and therefore show a blue dot, but as I write this, Firefox is showing me the dot on bugzilla.mozilla.org, asking me whether I want to enable Refined GitHub on it, and that makes absolutely no sense.

Whiteboard: [addons-jira]
Assignee: nobody → lgreco
Status: NEW → ASSIGNED

I just briefly checked the patch, but I don’t think it does the right thing if I understand correctly.

  • The problem is not the indicator at all. The indicator shouldn’t be displayed in the first place. The problem is that Firefox requires user interaction that was not required with Manifest V2 and is still not required in Chrome + Manifest V3.
  • Not only activeTab but also the tabs permission is affected, as I said earlier.
Pushed by luca.greco@alcacoop.it:
https://hg.mozilla.org/integration/autoland/rev/dbe7cd42ff01
Do not show the attention badge for mv3 extensions requiring the activeTab permission. r=robwu
Flags: needinfo?(tomica)

(In reply to Rob Wu [:robwu] from comment #13)

Perhaps we can implement optional_host_permissions (bug 1766026) and use that as a signal to opt out of the UI that notifies the user of the need to grant host permissions.

We should to this, whether in this bug or in a follow-up.

(In reply to Kohei Yoshino [:kohei] from comment #29)

I just briefly checked the patch, but I don’t think it does the right thing if I understand correctly.

  • The problem is not the indicator at all. The indicator shouldn’t be displayed in the first place. The problem is that Firefox requires user interaction that was not required with Manifest V2 and is still not required in Chrome + Manifest V3.

Please file a separate bug with reproduction steps, expectations vs reality, so we can continue the discussion when this one is closed due to the patch having landed.

  • Not only activeTab but also the tabs permission is affected, as I said earlier.

There is nothing special with "tabs" in the context of this bug.

Status: ASSIGNED → RESOLVED
Closed: 14 days ago
Resolution: --- → FIXED
Target Milestone: --- → 129 Branch

Verified as Fixed. Tested on the latest Nightly (129.0a1/20240701214557) and, for comparison reasons, on the latest Release (127.0.2/20240624183754) under Windows 10 x64 and Ubuntu 22.04 LTS.

Using “Duplicate Tab” (https://addons.mozilla.org/en-US/firefox/addon/duplicate_tab/) which is an MV3 extension requiring the activeTab permission, I accessed https://www.wikipedia.org/.
On Nightly, the attention badge is not shown, confirming the fix.
In comparison, on Release, the attention badge is shown, further confirming the fix in Nightly.

Status: RESOLVED → VERIFIED

Comment on attachment 9410701 [details]
Bug 1851083 - Do not show the attention badge for not granted origin permissions explicitly declared as optional. r?robwu!,zombie

Revision D215430 was moved to bug 1905931. Setting attachment 9410701 [details] to obsolete.

Attachment #9410701 - Attachment is obsolete: true

Comment on attachment 9409815 [details]
Bug 1851083 - Do not show the attention badge for mv3 extensions requiring the activeTab permission. r?robwu,zombie

ESR Uplift Approval Request

  • If this is not a sec:{high,crit} bug, please state case for ESR consideration: Users of ESR128 with an MV3 extensions installed and activeTab permission granted would still be shown the attention badge on all websites and extension developers that wants to support users on both the Release and ESR channels may decide to not migrate to Manifest V3 and instead staying on Manifest V2 until the next ESR.
  • User impact if declined: This bugfix makes sure Firefox will not be show the attention badge (on the extensions panel button, or the browser action extension button) on all websites when the user have an MV3 extension which has the ActiveTab permission granted. This has been in the past one of the major complains from users and extensions developers on Manifest V3 extensions (and some extension developers opted to migrate back to Manifest V2 to handle users complains related to the attention badge being shown on all websites).
  • Fix Landed on Version: 129
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): The patch includes a one line change to fix the issue (which is also restricted to just the logic computing the attention badge flag), plus changes to the expectations of the related tests to ensure the expected behaviors are covered by the automated tests.
Attachment #9409815 - Flags: approval-mozilla-esr128?

Comment on attachment 9409815 [details]
Bug 1851083 - Do not show the attention badge for mv3 extensions requiring the activeTab permission. r?robwu,zombie

Approved for 128.1esr.

Attachment #9409815 - Flags: approval-mozilla-esr128? → approval-mozilla-esr128+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: