Inconsistency: Permissions Inconsistency with New "SidePanel"

[stefanvd]

Google Chrome Canary v114 recently introduced the new "sidePanel" feature that allows users to view a sidebar alongside their web browsing experience. However, there seems to be an inconsistency in the permissions required for Chrome extensions to access this feature. While Firefox, Opera, and Naver Whale web browsers do not require any additional permissions for their extensions to access the sidebar, Chrome extensions need to request permission to use this new feature.

I recently created my first Note Sidebar browser extension, and I have noticed that there is an inconsistency in the permissions required by different web browsers for extensions to access the sidebar feature. This has led to confusion for browser extension developers who want to create a single codebase that can be used across different browsers. It is unclear why some web browsers, such as Firefox, Opera, and Naver Whale, do not require any additional permissions for extensions to access the sidebar, while Chrome does.
As a result, I wanted to raise awareness among web browser vendors and the extension community about this difference. It is important to bring back harmony in extension development by having a consistent approach to permissions required for accessing sidebar features. I hope that this post will help to facilitate a conversation around this issue and ultimately lead to a more unified approach to extension development across different web browsers.

Here is a list of names used by various web browsers for this feature:

Web browser	Manifest	Permission needed
Google Chrome	"side_panel"	"sidePanel"
Opera	"sidebar_action"	-
Naver Whale	"sidebar_action"	-
Firefox	"sidebar_action"	-
Microsoft Edge	"side_panel"	"sidePanel"
Safari	-	-

Overview of all the sidebar web browser APIs

GitHub sidebar/sidePanel sample for each web browser (Opera, Naver Whale, Firefox, and Google Chrome):

https://github.com/stefanvd/Browser-Extensions/tree/master/Note-Sidebar

Resources:

• https://www.stefanvd.net/blog/2023/05/06/how-to-create-a-sidebar-chrome-extension-mv3/
• https://bugs.chromium.org/p/chromium/issues/detail?id=1378048
• https://developer.chrome.com/docs/extensions/reference/sidePanel/#manifest
• https://learn.microsoft.com/en-us/microsoft-edge/extensions-chromium/developer-guide/sidebar

UPDATE 22 July 2023, add Microsoft Edge sidePanel permission

[bershanskiy]

Firs of all, Sidebar Action API (Chromium-exclusive) and Side Panel API (Firefox-/Opera-/Naver-exclusive) are two different APIs which on surface aim to support similar use cases, but are actually completely different. It would be nice if all browsers could agree on a single API to begin with. As of now, the two APIs don't even match in their capabilities let alone the API names and permission name.

Closer to the subject, I agree that permission consistency is very important (for both users and developers), while also I think explicit granular permissions are better (for users). I hope Chromium retains the permission and Firefox/Opera/Naver add their own permissions too.

[bershanskiy]

Another related issue is messaging initiated from background context to the sidebar. Currently, messages are routed based on tabId (and frameId), but sidebars typically lack this pair.

[fregante]

but are actually completely different

That's the issue. I'm not sure why Chrome decided to implement a brand new API without following Mozilla’s, which has existed for a long time.

Another related issue is messaging initiated from background context to the sidebar

You can use chrome.runtime.sendMessage to contact every open chrome-extension:// page, including the background page, so you can already do that.

[Rob--W]

Chrome had published a design document called "Extension API Proposal: Side Panel" document, which includes Google's motivation for diverging from the existing APIs. The relevant section is at https://docs.google.com/document/d/1bWM4oMj-3Bzp_ixtG5qkPWESCOfwAWJRUMXavxVswIM/edit#heading=h.7p4gqdn4ksj6 and its content is quoted below:

Alignment with Other Vendors and Action APIs

Other browser vendors provide a conceptually-similar sidebarAction API (see Firefox's here); Chrome also pursued a sidebar API implementation in the past. These implementations very closely align with the action-related APIs (action, pageAction, and browserAction). This alignment can make sense, as both APIs allow the extension to set a visible UI surface with configuration options (and, arguably, a side panel can be viewed as a "sticky" version of a popup). Whether to align with these APIs was a consideration in this design, but was ultimately decided against.

The action-style API surface has a number of drawbacks when applied to the sidePanel API:

• They use multiple configuration functions rather than a single function (see above).
• The applicable fields (may) not align. In this first iteration, the side panel does not provide options for setting the icon or title; in future iterations, it may provide more customization (such as providing matches and excludeMatches properties).
• Methods like 'getUserSettings()` are (currently) inapplicable to the side panel.

Additionally, though these APIs share a good amount of "implementation similarity" (in Chromium, the side panel settings could be implemented with the existing ExtensionAction class), this similarity is likely not shared by users, who are more likely to view these as distinct and separate UI surfaces. Finally, the action-related APIs are all mutually-exclusive in Chromium (an extension may only have one of an action, browserAction, and pageAction), and all refer to toolbar-positioned icons - both of these do not apply to the side panel. This is exacerbated by the possibility of the toolbar action click itself opening the side panel (see section below).

These drawbacks lead us to diverge from the action-style APIs.

The question remained of whether to align on naming with other browser vendor APIs (which favor "sidebar" instead of "sidePanel"). The "sidePanel" naming was chosen for two reasons:

1. In an attempt to disambiguate this API from the APIs offered in other browsers (which, due to their alignment with action-related APIs as described above, are distinct and have a different API surface). This should hopefully highlight to developers that these have significantly different method signatures and different capabilities.
2. In Chromium, the UI surface is titled the "side panel", which provides a ready-made alternative to “sidebar”.

[oliverdunk]

@Rob--W asked if we could investigate the possibility of implementing the sidebar_action API for compatibility. I'm not sure if that's something we've considered so I'll follow-up.

[stefanvd]

Update add Microsoft Edge extension sidebar, which is using "sidePanel" permission:
https://learn.microsoft.com/en-us/microsoft-edge/extensions-chromium/developer-guide/sidebar

[rdcronin]

Realistically, I don't think this is something Chrome will do.

We deliberately diverged in namespace from the Firefox API because the APIs were sufficiently different from one another, and are unlikely to converge in the near future.** Because there are enough differences between the APIs, we don't want to conflict or imply that they are (or should be) equivalent.

Realistically, extensions will likely need to have differences between browsers (e.g. implemented as a step in an automated packing flow, etc). Given this and the fact that these aren't the same API, Chrome's not likely to "alias" sidebar_action to sidePanel.

(In terms of if other browsers wanted to add a permission for sidebar / sidePanel, I have no strong opinion.)

** This community group is still growing and evolving. At the time we designed the sidePanel API, we didn't have as much alignment or as clear of processes as we do today. It's unclear if we necessarily would have gone the same route if we designed the API today, but we aren't likely to change this API in the near future.

[zombie]

From the Firefox side, we don't plan on adding a permission for this feature (in either form), as that would be a backward-incompatible change for existing Firefox extensions.

[oliverdunk]

At TPAC we discussed this issue and noted a couple of things:

• The specific ask in the issue is around consistent permissions. Given the different APIs, and that adding a permission would be a breaking change in Firefox, this does not seem desirable.
• While this issue has been used for some general discussion around chrome.sidePanel vs browser_action, there isn't a clear next step there, and it isn't what this issue was originally opened for.

Given these (and the above comments), closing this out for now.