1806305 - Allow users to hide/remove the unified extensions button from toolbars

Status: RESOLVED WONTFIX

(WebExtensions :: General, enhancement)

Description

[aoia7rz7l]

Users currently (110.0a1 (2022-12-16) BuildID 20221216093922) cannot hide/remove the unified extensions button via the Remove from Toolbar context menu item. I believe bug 1781773 was partially tracking this originally but that was dropped because it was no longer a "widget" (not sure why)? I can still disable the button by flipping extensions.unifiedExtensions.enabled to false and restart, but:

1. Anything under unified-extensions-area in browser.uiCustomization.state will be moved to widget-overflow-fixed-list when I disable the button. I ended up having to remove all browserActions that I have hidden prior to the puzzle button rollout again, because they were automatically added to unified-extensions-area.

2. While I am perfectly happy to just leave this pref'ed off, I am expecting to be told that extensions.unifiedExtensions.enabled is another rollout pref and will be deprecated at any point.

IMO This isn't really helpful when a user tries to limit the number of browserActions in the toolbar to avoid the overflow menu, only to be forced to live with it in another form.

I tried digging into MV3's spec for any justification for the existence of this extra button but there is only:

https://developer.chrome.com/docs/extensions/mv3/intro/platform-vision/#improved-user-visibility-and-control

The extensions platform will provide greater user visibility and control, so that users can more easily manage how extensions access their data and other resources. The platform already begins to address this by:

Letting the user modify the host permissions granted to extensions
The extensions menu showing which items can or want to access the current page

We'll continue to improve this user experience. Look for an increasing emphasis on temporary, in-context style of permissions grants, constraining passive access to user data. The introduction of activeTab was an initial step in this direction.

It's also important that users make informed decisions about how their data is handled. We'll be introducing new ways to help users understand what data each extension accesses and how it uses that data, so that users have control of their data.

https://developer.chrome.com/docs/extensions/mv3/intro/platform-vision/#a-new-approach-to-user-data-access

Many extensions rely on persistent access to user data: the user gives access permission on installation, and the extension can then access the data at any time. We're moving away from this model of persistent access. Instead, we want to let users grant permissions temporarily and only in the context where they're needed.

The current implementation in Chrome does not actually allow users to do anything useful though, beyond pinning and unpinning browserActions. Anything else will inevitably involve opening chrome://extensions, and that has always been possible even without this new button.

But that's not it though:

https://developer.chrome.com/docs/extensions/mv3/intro/platform-vision/#manifest-v3-related-changes

Manifest V3 related changes

There are a number of features that aren't actually part of Manifest V3, but are scheduled for release in the same time frame. These features are related to Manifest V3 in that they impose new requirements that Manifest V3 is designed to address.

The key feature launching in this category is the changing way that host permissions are granted. Again, this isn't an Manifest V3 feature, but it does motivate Manifest V3 changes. Expect these changes in early 2021.

The initial steps in this area have already launched:

The ability to modify an extension's host access (see Trustworthy Chrome Extensions, by Default).
Moving extensions out of the right-click menu and into a button on the extensions menu (see A new home for your extensions).

https://blog.google/products/chrome/more-intuitive-privacy-and-security-controls-chrome/#:~:text=A new home for your extensions

Starting today you’ll start to see a new puzzle icon for your extensions on your toolbar. It’s a neat way to tidy up your toolbar, and gives you more control over what data extensions can access on sites you visit. With this addition, you’ll still be able to pin your favorite extensions to the toolbar.

Opening menu displays your extensions and shows you what data they can currently access.

So the unified extensions button isn't even strictly part of MV3 spec? If that's true then why ape another pointless Chrome "feature"? Besides, the current Firefox implementation already deviates enough to limit some of the purported "benefits". These deviations include:

1. browserActions are not tied to the unified extensions button (bug 1777489 comment 1)
2. browserActions pinned in the toolbar are not visible in the unified extensions panel (bug 1799846)
3. Extensions that supplied a valid default_area (e.g. Temporary Containers) are not visible in the unified extensions panel by default (bug 1799947)
4. browserActions can (eventually) be manually hidden from the unified extensions panel (bug 1800883)

So why not let users hide this button to save precious space in the navigation bar, if they wanted to? Also, are we really expecting downstream browsers (e.g. Thunderbird) to just live with this?

Comment 1

[Alex Cornestean]

Hello,

As you already mentioned in the report, the unified extensions button cannot be removed/hidden from the UI. This is an intended change and thus what you are proposing is an enhancement, rather than a defect. As such, I will mark the report accordingly.
For the moment, only by flipping the extensions.unifiedExtensions.enabled pref to false will revert to the previous implementation, as you also mentioned.

Comment 2

[Tomislav Jovanovic :zombie]

(In reply to aoia7rz7l from comment #0)

2. While I am perfectly happy to just leave this pref'ed off, I am expecting to be told that extensions.unifiedExtensions.enabled is another rollout pref and will be deprecated at any point.

You're correct, setting that pref is not a supported configuration, and will likely be removed at some point in the future.

So the unified extensions button isn't even strictly part of MV3 spec? If that's true then why ape another pointless Chrome "feature"? Besides, the current Firefox implementation already deviates enough to limit some of the purported "benefits". These deviations include:

There is no "mv3 spec", and this is not a "Chrome feature".

Our reason for the new button and panel is to enable users to see and control host permissions for extensions which might not have a browser action (or which users don't want/need to have pinned to the toolbar).

So why not let users hide this button to save precious space in the navigation bar, if they wanted to? Also, are we really expecting downstream browsers (e.g. Thunderbird) to just live with this?

If there is even a single extension that you rarely use, you can unpin it from the toolbar and get your precious space back. If you have two or more similar extensions, unpinning them is net positive for your toolbar space.

We're also using the new button to "anchor" install prompts and other notifications for extensions which are not visible in the toolbar, so that's why it can't be removed.

I don't really know much about Thunderbird, but I don't see why they couldn't use a similar UI to get some of the same benefits.

Closing as wontfix, because the current behavior is by design.

Comment 3

[aoia7rz7l]

(In reply to Tomislav Jovanovic :zombie from comment #2)

There is no "mv3 spec", and this is not a "Chrome feature". Our reason for the new button and panel is to enable users to see and control host permissions for extensions

Sure. It's just that Mozilla's implementation of this "button" is surprisingly similar to that of Chromium.

Our reason for the new button and panel is to enable users to see and control host permissions for extensions which might not have a browser action

You can always allow users to control host permissions in about:addons instead. In fact Chrome already allows users to do so via chrome://extensions for quite some time (possibly even before MV3 is a thing). Are we really not expecting users to be able to navigate about:addons now?

browser action (or which users don't want/need to have pinned to the toolbar).
If there is even a single extension that you rarely use, you can unpin it from the toolbar and get your precious space back

Have you considered the case where there is a single extension that a user does use that does not have a browser action (plenty in MV2), and this non-removable unified extension button that the user doesn't use is exactly occupying that precious space?

because the current behavior is by design.

Chrome's design is bad but you don't have to follow it all the way. IMO this is another backward argument just like in bug 1698931.