Proposal for sidePanel lifecycle events. #779
Conversation
Partial draft
Added the remaining sections.
Updated schema: - added PanelInfo - Removed reasons Removed un-asked use cases Elaborated on the workarounds Added points to the open discussions
Updated workarounds
Updated reasons in open discussions.
Fixed typos
Moved content from future work to Open discussions.
|
Related issue: #693 |
|
Gentle reminder for reviews on this @Rob--W, @oliverdunk, @xeenon. |
carlosjeurissen
added
the
topic: sidebar
| } | ||
| } | ||
| ``` | ||
| - Would adding onHidden, onShown or onVisibilityChanged events for side panel extensions make sense too? |
There was a problem hiding this comment.
As discussed in the last meeting, I am waiting until there is more discussion in the proposal about this before doing a full review.
|
Hey! I have two questions about the current proposal:
The spec says this event is fired when a side panel is closed. But it’s not clear who will receive this event. Can you confirm if this event is only sent to the extension that originally opened the side panel? It would be helpful if this behavior could be made clear in the spec.
Is it necessary to include the path property in the event payload? Since the extension itself sets the path when it opens the side panel, it can maintain the context internally and can track this information on its own. Also, there isn’t a standard pattern in other extension APIs where |
Creates a proposal for the extensions sidePanel API events which will cater to basic lifecycle events like onClosed and onOpened.