PSA: Google I/O and chrome.sidePanel API

[Oliver Dunk]

Hi everyone,

I just wanted to quickly share that our Google I/O talk “What’s new in Chrome Extensions” is now available to watch: https://www.youtube.com/watch?v=QYd2XiUYNlE

We shared some more of our thinking around Manifest V3, and as part of that, we just published an update to the Known Issues page: https://developer.chrome.com/docs/extensions/migrating/known-issues/

In addition, we mentioned the upcoming Side Panel API, which is now available for testing in Chrome Canary: https://developer.chrome.com/docs/extensions/reference/sidePanel/. You can find some sample code in the chrome-extensions-samples repository: https://github.com/GoogleChrome/chrome-extensions-samples/tree/main/functional-samples

We’re working on updating more of our documentation, and will be sharing some additional guidance and best practices for using the Side Panel API when it is released in Stable.

Thanks,

Oliver

[wOxxOm]

The known-issues page says "All extension events and API calls will extend the service worker lifetime" which is false because only asynchronous chrome API calls will do it, not all. If your want to keep misrepresenting this unintentional bug as a feature you should at least make it technically plausible.

[wOxxOm]

Looks like it's about to be fixed in https://crbug.com/1423190. Judging by the code in review the SW will be kept alive only during the API call, same as in an MV2 event page. Apparently, the bug was caused by the fact that these calls internally reused the same IPC mechanism as the full-fledged SW events.

[Stefan Van Damme]

Hi everyone,

Great to see a YouTube video about the new points in Chrome extensions.

|| In addition, we mentioned the upcoming Side Panel API, 

I wrote this breaking news on my blog (a few days ago), if you are a new beginner check the side Panel tutorial and overview of all web browsers:

https://www.stefanvd.net/blog/2023/05/06/how-to-create-a-sidebar-chrome-extension-mv3/

Example code for all browser extensions (Chrome, Opera, Firefox, Naver Whale):

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

Example of the first published Note Sidebar Chrome extension on the Chrome Web Store:

https://chrome.google.com/webstore/detail/note-sidebar/emiochiflnnegkecnjndifbobmbepdne

Thanks,

Stefan vd

[Uladzimir Yankovich]

Oliver, hey 👋

Do you know when the Side Panel API will enter the stable channel? 

Do you have a roadmap for developing this API for the next year? At least a set of hypotheses.

This is critically important for me as a developer https://manganum.app/ 🥹

[Oliver Dunk]

Hi Uladzimir,

At the moment we're suggesting testing in Chrome Canary, since the API is fully enabled there.

We're working on making sure all of the changes to enable it are merged back to 114, so hopefully by the next 114 beta it will be available there too - and then this should ship when M114 goes to stable :)

As far as a roadmap, nothing too specific, but we're definitely open to feedback. One thing I know we are keen to hear about is other triggers for opening the side panel (e.g from a context menu item) that would be useful.

Thanks for the questions!

Oliver

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/52d1d48a-0b2e-46d4-8d10-b0e1ad231da3n%40chromium.org.

[Oliver Dunk]

The known-issues page says "All extension events and API calls will extend the service worker lifetime" which is false because only asynchronous chrome API calls will do it, not all.

Thanks for calling this out (and for your patience, I wanted to make sure we properly addressed this). You're right that there are some exceptions (my understanding is that some API calls happen entirely in the renderer process, and these don't currently extend the lifetime). All other API calls (the vast majority) do extend the lifetime though, and these also happen to be the ones which are expected to take longer to execute, so I think that mostly makes sense. It's definitely confusing for developers though.

I've opened a bug to track this: https://bugs.chromium.org/p/chromium/issues/detail?id=1446810. One possible resolution is just fixing this which would be a nice win for consistency and avoid the need for developers to understand the different behaviours.

Looks like it's about to be fixed in https://crbug.com/1423190. Judging by the code in review the SW will be kept alive only during the API call, same as in an MV2 event page.

I checked with the engineering team on this one (and tested locally), and this is just a refactor which should not affect any behaviour.

Please do comment on the relevant bugs if you think we've missed anything. We genuinely want to make everything as clear as possible and appreciate the feedback.

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

[wOxxOm]

I've commented there with a short summary explaining why the change violates specification, logic, developer expectations, and platform integrity. I didn't mention how it makes behavior of extensions inconsistent in different browsers yet, because it doesn't seem a frequent concern for the Chrome Extensions team.

[Oliver Dunk]

Morning all 👋

I wanted to share a couple of quick updates on the Side Panel API:

• The API is now available in Chrome Beta! We merged a final change to M114 and from here, the API should hopefully follow the release schedule for that version: https://chromiumdash.appspot.com/schedule
• We're doing some early experiments around adding an API to programmatically open the Side Panel: https://crbug.com/1446022. The API overview doc isn't public yet (hopefully soon) and I'll do another post when it's in a better place for testing. I also want to be clear that this may not ship in the current form or at all. But I wanted to let you all know regardless, since I know that's been a common feature request.

Thanks, and do keep the feedback coming!

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

[Uladzimir Yankovich]

Oliver, thanks for keeping us informed 🤗

--
You received this message because you are subscribed to a topic in the Google Groups "Chromium Extensions" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/chromium-extensions/cJmdMLmpbjg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to chromium-extens...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/CAOsQqBnT2qBGz22CPLgtXhAhUL2yFFYtPAc30ryRG%3DMtZ1YPQA%40mail.gmail.com.

--

Uladzimir Yankovich,

Founder @ Manganum (manganum.app).

[Uladzimir Yankovich]

A little more feedback about our journey with the side panel 🥹

1. the browser doesn't remember the side panel width settings set by the user. It concerns both restarting the browser and creating a new window. It seems like it would be better if the browser remembered. Also, it seems that my feedback about being able to set the minimum width of the sidebar for the extension is also relevant.
2. The trick of trying to track the visibility of our extension in the side panel via document.hidden or via clients.matchAll() didn't work. When the user switches between OS applications or minimizes the browser, we get a message that the document is invisible, which makes sense. So we need a native sidepanel API method to report show/hide and window Id accurately.

[Oliver Dunk]

Thanks Uladzimir!

Noted on the first one - that one is slightly interesting because it's sort-of an extension thing, but we'd also likely want it to be consistent with how resizing works for the built-in panels. I'm not saying we can't do anything, just wanted to mention that I can see it being a harder change for that reason. It seems like there's definitely been a lot of feedback on sizing and hopefully we can figure out something there.

Appreciate the updates on visibility. It sounds like knowing if it's open would be solved by runtime.getContexts(), although an event would be nicer to avoid polling. And then knowing when you've switched between different Side Panels is something we haven't found any solution for. Does that seem like a fair summary?

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

[Uladzimir Yankovich]

Yes, I understand. That in matters of size control is difficult for you. Historically, sites have not had the ability to control their window. Whereas extensions have always had that capability.

But, it seems to me that at the very least, the browser should remember the width of the sidebar set by the user. Just like now the browser remembers the size of the window.

Still, I'd be glad if you could discuss the possibilities of specifying a minimum width. I understand that extensions are supposed to be adaptive, but you settled on 320px width as the default. This is a mobile format. And not all extensions will be able to fit into it. And I don't think Chrome will agree to increase the default panel size. Although I think 400px would be better :)

About being able to determine exactly the status of the panel.

We found a solution to know when the user switches between the sidebars. The problem is that we get false positives when the user switches between OS windows or minimizes the browser.

So yes, at a minimum, we would like a getContext method that tells us about all existing sidebars and also returns their windows Id and actual visibility.

That would be good. But with this solution, we would be polling this method every second. The ideal solution would be to get the getContext.Changed event in addition to this method. So that we could drop the polling but be notified when a new panel has appeared, or one of the existing ones has lost visibility.  

[Jackie Han]

The trick of trying to track the visibility of our extension in the side panel via document.hidden or via clients.matchAll() didn't work. When the user switches between OS applications or minimizes the browser ……

When the side panel or the browser window is not visible, there is usually nothing to do. Generally the side panel only provides functionality when it is visible.

You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/CAFc1iR7_bLWLcGaeMcqK74HLK6BrNckF4LXB7xO281uJ-_C5AA%40mail.gmail.com.

[Uladzimir Yankovich]

I agree that this is often the case, but not always, such as in our case.

[Uladzimir Yankovich]

We are still on the road—fresh feedback.

1. It would be cool to know the current position of the side panel (left or right side). We have a need to implement a responsive UI, but this is not possible until we know the current position of the panel. And of course, an event if the user changed the setting to avoid endless polls.

2. +1 from me to the ability to call the panel programmatically using a user gesture. Right now, onboarding design is either a nightmare or a lottery.

3. Everything I said in previous messages 🤣

[Oliver Dunk]

Thanks for the continued feedback!

Continuing to make mental notes of all of these.

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

[Uladzimir Yankovich]

One more thing...

We can't use Web Speech API from the side panel 😭

To be precise, you cannot initialize the permission dialog from the side panel. But if you have permission, the API will work. 

[Jackie Han]

To be precise, you cannot initialize the permission dialog from the side panel. But if you have permission, the API will work.

 

I didn't test. But I know there is a bug with requesting web permissions in the popup page. So, you may need to open a tab to ask the user for permission.

[Simeon Vincent]

I didn't test. But I know there is a bug with requesting web permissions in the popup page. So, you may need to open a tab to ask the user for permission.

 

It's unfortunate that you can't create a permission request in the sidebar as the UX to get that permission will end up being pretty clunky.

A common flow on mobile is to show a prompt saying you need permission and a button saying "Request permission". Once that button is tapped, the system permission request dialog would appear. I think you may be able to adapt this flow to fit your needs.

While it's true that the sidepanel doesn't allow you to display permission prompts, you can open a new window with type: "popup" (not the extension popup) and use that to initiate the permission request flow. In my testing just now I opened a popup by calling this block in the sidebar.

navigator.permissions.query({name: "microphone"}).then((res) => {

if (res.state == "prompt") {

chrome.windows.create({

url: "mic-permission-req.html",

type: "popup",

height: 200,

width: 300,

});

}

});

Then, in the popup's JS you can immediately call navigator.permissions.request({name: "microphone"}); to initiate the permission request flow. IMO it might be better to explain to use the prompt to explain that in order to do X the user will have to grant you extension microphone access, then initiate the permission request flow when the user clicks the "request" button. If the user has accidentally denied the permission, this approach also gives you the opportunity to explain the problem and to direct them to the extnesion's settings page  to fix it (chrome://settings/content/siteDetails?site=chrome-extension%3A%2F%2FEXTENSION_ID%2F).

Simeon - @dotproto

incremental.software

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/CAAgdh1%2BO05DnawsTzHwLEM%2BzXXwe%3Dsbyeay5ieUF9L9Rn17PBw%40mail.gmail.com.

[Simeon Vincent]

Oops, I forgot to revise my first sentence before I hit send. While the flow I suggested is a little clunky, I think it will likely be reasonable in practice.

Simeon - @dotproto

incremental.software

[Patrick Kettner]

I agree that it the webspeech limitation is silly. With geolocation, we offer a manifest permission explicitly to allow for folks to grant permission in a different way to the normal flow. I created a bug to add the same for webspeech. Thanks for bringing it up, @Uladzimir!

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/CACA%3D7_Z0k1O7u20Rc9er56Uh-gFDe8P_rPoyZiQ8u4PfuiZTRg%40mail.gmail.com.

[Uladzimir Yankovich]

Colleagues, thank you for your input!

Talking about permission to access the Web Speech API, I keep in mind a recent discussion in one of the neighboring threads. There we talked about permissions.

I think the geolocation and microphone permission examples are great examples of permissions that could only be available as optional permissions.

[Patrick Kettner]

great point! do voice any input on the bug to make sure it goes through the dev teams triaging

[Jackie Han]

Uladzimir already gave feedback two times about "the browser should remember the width of the sidebar set by the user". Last Friday, I published a sidebar extension, a user also gave feedback about this. Currently, the browser only remembers the width in a session of a window, when opening a new window or closing the current window, the browser forgets the last width of the sidebar. This causes the user to adjust the width frequently. Usually on the same monitor, the user wants to be able to set an optimal fixed width for them.

You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/CAOsQqB%3DmL%2BcnoQUULAxJYSCQQzMCxw%3Dgfrb%2B6pYRw26HjqJhTw%40mail.gmail.com.

[thdoan]

Here are some notes after experimenting with the sample side panel extension...

1. Very exciting new extensions API, but in its current form it's yet to reaching its full potential for many of the same reasons already discussed in this thread (mainly: cannot open it programmatically, side panel size not saved across sessions, no events for side panel visibility & enabled states).
2. File this under good-to-have: I wish there was a Chrome setting to set the padding inside the side panel. On Chromebooks with smaller screens, we're trying to squeeze every last bit of screen real estate we can. I get that it's currently 16px because the resize handle is 16px wide so it makes for an even border, but it's not too uncommon to see resize handles that are 8px wide, so the padding can be as small as 8px, saving a total of 16px in each axis.
3. Still, I'd be glad if you could discuss the possibilities of specifying a minimum width. I understand that extensions are supposed to be adaptive, but you settled on 320px width as the default. This is a mobile format. And not all extensions will be able to fit into it. And I don't think Chrome will agree to increase the default panel size. Although I think 400px would be better :) -- This is a more complex request because all side panel extensions as well as the built-in side panels share the same component. I guess one solution is to allow developers to set a minimum width for their own extension only, but this would result in a UX where the side panel width could jump every time you change side panels.
   
4. When the side panel or the browser window is not visible, there is usually nothing to do. Generally the side panel only provides functionality when it is visible. -- All the more reason why we need chrome.sidePanel.open() ASAP :-). I wasn't able to expand the sample dictionary side panel extension in the way that I'd like because of current limitations. Imagine this scenario: you select a word, click "Define" from the context menu expecting to see the definition show up in the side panel, but nothing happens because (1) the side panel is closed or (2) the side panel is open but your extension is not the active side panel. Since we're not able to programmatically open the side panel and switch to our extension in the side panel, an entire category of extensions is not possible (operate on text selection, output to side panel).
   

[Jackie Han]

`sidePanel.open()` will be available in Chrome 116.

Source: https://bugs.chromium.org/p/chromium/issues/detail?id=1446022#c14

[Wang Dàpéng]

Glad to hear that!

[Uladzimir Yankovich]

Now it becomes even more relevant to have a method and callbacks to determine the state of the side panel 🥹

[c luo]

Now I use a sendMessage with a specific response to determine wether the side panel is opened.😅

[Uladzimir Yankovich]

Release 116 is coming out soon, which means we'll get sidePanel.open() and chrome.runtime.getContexts(). It is perfectly.

However, I would like to refresh other requests that are still relevant. And synchronize it with the actual plans of the Chrome team.

1. Side panel width control. Several developers have already expressed a request for this feature. And all referred to the requests of their users.

2. Side panel visibility state and events. chrome.runtime.getContexts() doesn't tell if the panel is visible. In some cases, this is critical to delivering a good UX. In addition to the ability to get the state, it would be great to have an event about changing this state.

3. Linking the side panel to the browser window. Right now, chrome.runtime.getContexts() always returns 'windowId: -1' for side panels. This is not true. Since, in fact, the panel is always attached to the window. And to determine this bundle, you have to use tricks.