Giters

w3c / webextensions

Charter and administrivia for the WebExtensions Community Group (WECG)

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

`sidePanel` API: lifecycle events

fregante opened this issue · comments

commented

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
  • sidePanel.onUnload (the document/context is unloaded/closed)
    • impossible via chrome.runtime.connect's onDisconnect 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

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.

commented

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.

commented

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.

commented

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.