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