`sidePanel` API: lifecycle events
fregante opened this issue · comments
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:
- sidePanel.onLoad (the document/context is loaded)
- somewhat possible via manual
.sendMessage
to all the relevant contexts
- somewhat possible via manual
- sidePanel.onUnload (the document/context is unloaded/closed)
- impossible via
chrome.runtime.connect
'sonDisconnect
event if there are multiple sidebars open, because the connection is preserved across instances: https://stackoverflow.com/a/36465331 - impossible via
onbeforeunload
because.sendMessage
doesn't complete
- impossible via
Some other more specific events could be:
- sidePanel.onShow (like
visibilitychange
, the current extension's sidePanel is shown) - sidePanel.onHide (the user selects another extension's sidepanel)
These two are less important, I suppose a local visibilitychange
+ runtime.sendMessage
could work as well.
+1 🙏.
Here are my similar requests - https://groups.google.com/a/chromium.org/g/chromium-extensions/c/cJmdMLmpbjg
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.
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.
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.