Proposal: `action.default_area=navbar` and `action.default_area=hidden`

[carlosjeurissen]

Background

Mozilla Firefox supports the default_area property of the action manifest key. See: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/browser_action#syntax

In addition, Google Chrome nowadays hides extension action buttons in an "extensions" dropdown menu. To keep the interface clean and show all installed extensions in this menu.

Use case

For some extensions, it's very important to be directly pinned from the start especially when the extension has a menu of options, like https://chrome.google.com/webstore/detail/bookmarks-menu/ffmdedmghpoipeldijkdlcckdpempkdi
Hiding the extension icons by default hurts the core features of such extensions. Not all extensions purpose are to act on the current page but just add additional UI to the browser.

This info could then be used by the browser to offer pin suggestions, like proposed in #199.

Solution

My proposal is to add support for the values hidden and navbar for action.default_area in all browsers. This allows the extension developer to indicate to a browser whether or not it's important to be pinned by default. The browser can then decide if and how in their UI they want to facilitate this.

The value navbar would indicate the webExtension prefers to be pinned right from the start. While the value none would indicate the webExtension is not at all interested in being exposed in the UI. This value could be ignored by browsers who prefer to always display extension icons for transparency and security reasons.

[hicallmeal]

Personally, as a user and developer, I'm more on the side of user agency.
A majority of extensions pinning themselves may lead to toolbars of ye olde (IE). I would think vendors are trying to avoid that.
Whilst you could argue that users have the same agency to unpin, extensions are less likely to guide them on that (then they are to instruct to pin them).

I know I'm in the minority of developers with this sentiment, but still, I think it's important to think of the users with UI things like this. After all, we make extensions for them, not us.

I do of course acknowledge your point/s - extensions tucked away may suffer from limited use and lead to confusion.
Though with guidance, I think most users should be able to do it themselves.

The browser can then decide if and how in their UI they want to facilitate this.

I could see that perhaps it affects whether the Browser itself guides the user, in the post-install prompt -

For those with the key present, it could provide the steps to pin. Those without, perhaps the dialog would either be minimal or not present (probably not good). Then users have the agency and know-how to pin.

Or even, the browser could prompt the user, like the above dialog (or within it) if they'd like to pin. Again, the user has the agency and this time they don't even have to do it themselves.

At the very least, what should be clear and easily instruct-able is *how* to pin.
Chrome(ium) will soon remove the pinning icon and move to text-based items, which had prompted discussion when it was announced. Many sharing OP's sentiment.

Announcement
CRX Group - Further Discussion

[carlosjeurissen]

@hicallmeal As a developer who received a lot of feedback from users with questions like "where is the extension button" "how to open the extension", I question if it is really better for the user if extension developers can not articulate to browsers if their extension should be pinned or hidden by default. Hypothetically browsers could offer users a preference to either display or hide the extensions by default.

In general UI decisions are out of scope for this group. Which is why I am proposing a way to articulate as extension developer if a specific extension should be pinned or not by default. This would be an opt-in for extension developers, so I do not expect expect all extensions to all of a sudden set their default state to pinned. In the end it still comes down to browsers on how to deal with the preference specified by the developer and whether or not to respect that. However at least with this proposal there is a way to articulate this preference.

[Juraj-Masiar]

Forcing users to do extra manual steps after installation is a terrible UX.
And forcing fellow developers creating extra "How to" tutorials is just mad.

And you can already see how annoying it is - in iOS Safari, where extension that you've just installed, you can't use, because it's disabled. So you need to go to Settings / Safari / Extensions and enabled it there (and it still won't work because you need to enable permission to access all pages!).
And since average people have no idea they need to do this, developers will make post-installation videos and tutorial pages (example page) just to show this procedure.