w3c / webextensions

Charter and administrivia for the WebExtensions Community Group (WECG)
Other
578 stars 50 forks source link

`sidePanel` API: lifecycle events #517

Open fregante opened 5 months ago

fregante commented 5 months ago

Our extension uses sidebar to display extra content about the current website, the content script communicates to the sidebar, acting as a controller.

It would be useful to have more control over it, specifically, to only do operations when the sidebar is open or know when it's opened/closed.

Proposal: lifecycle events

Some example useful events could be:

Some other more specific events could be:

These two are less important, I suppose a local visibilitychange + runtime.sendMessage could work as well.

yankovichv commented 5 months ago

+1 🙏.

Here are my similar requests - https://groups.google.com/a/chromium.org/g/chromium-extensions/c/cJmdMLmpbjg

tophf commented 5 months ago

sidePanel.onLoad (the document/context is loaded) somewhat possible via manual .sendMessage to all the relevant contexts

It's unclear what benefits an event would provide that aren't achievable just as easily via sendMessage. An example of code might be helpful.

yankovichv commented 5 months ago

Why can't you use the existing DOM visibilitychange event in the side panel to inform the connected content script?

Any tricks 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.

tophf commented 5 months ago

I see, so onShow/onHide or onVisibilityChanged event is necessary, but I don't see the need for the other two (onLoad/onUnload).

yankovichv commented 5 months ago

Yep, this, this is not so critical.

Although I would like to have such a common event for all contexts that may occur in chrome.runtime.getContext - https://developer.chrome.com/docs/extensions/reference/api/runtime#method-getContexts

For now, it’s easier to use a poll every 5 seconds.

tophf commented 5 months ago

I wouldn't call frequent polling an acceptable workaround. The point in my comments above was that this should be already possible via Port events.

fregante commented 5 months ago

Polling is not an alternative. By that suggestion, you don't need almost any events, you can just poll it.

Events are useful specifically because they let you avoid polling. That's the whole point of events: you want to respond to changes immediately without continuously waking up the background worker.