Proposal: close() Method for the sidePanel API

[hharshas]

This proposal introduces a sidePanel.close() method (among work items for Summer of Code).
While not fully fleshed out, it outlines the core idea. Initial feedback is welcome. I would also like your thoughts on the need for a user gesture for this. #521 #chromium

[dotproto]

All changes requested in this review are either internal styling consistency or GFM rendering fixes.

[dotproto]

I would also like your thoughts on the need for a user gesture for this.

Developers can currently close the document in the sidebar or sidepanel ("sidebar" for simplicity) by calling window.close() inside the sidebar document in Firefox and Chrome. This flow does not require user activation. Introducing a user activation requirement in a new sidebar.close() method would create an unexpected point of friction compared to the current solution.

There are times when it might make sense to diverge or to change existing behavior to also require a user activation, but I don't think this is such a case. As I see it, there's minimal risk to allowing an extension to close it's own sidebar, especially since both supporting browsers currently require user activation to open a sidebar. The main risk I see is that an extension might try to close a side panel right before a user clicks in order to cause the user to click something they didn't intend to in the main document, but I'm not sure how practical that kind of attack would be.

At the moment I'm comfortable with not requiring user activation, but I'll defer to @Rob--W for a more official position.

[oliverdunk]

I left one comment, but otherwise this seems like a good proposal.

[hharshas]

@carlosjeurissen While preparing the proposal, I was not in favor of throwing an error when the side panel is already closed for the given context. To keep things simple, an error should only be thrown if the context is invalid. Otherwise, it should simply do nothing and resolve, indicating that the panel is already closed for that context. If the side panel is opened globally for a window and we try to close it for just one tab, it will close for all tabs in that window.

[oliverdunk]

We should make sure to align on the behavior when both windowId and tabId are specified. Otherwise, LGTM.

[carlosjeurissen]

1. as mentioned in Proposal: API to Query Side Panel Layout #838 (comment), it would make a ton of sense to align on a unified sidebar API as proposed in Proposal: agree on a unified sidebar_action API for mv3 #128

2. We should clarify the difference between hiding vs closing the sidebar and the implications.

3. As was discussed briefly in the last call, the behaviour if both windowId and tabId and if a global side panel is visible on the given tabId. Why should it close the sidePanel for all tabs instead of simply throwing an exception? The intention of the developer is to close it for a specific tab. Closing the global sidePanel can be an unrequested side-effect. If an exception is thrown, a developer can always call close without a tabId to get this kind of behaviour. Yet it seems this should be optional, not enforced.

[hharshas]

2. We should clarify the difference between hiding vs closing the sidebar and the implications.

Currently, the focus is on using "close" when the intention is to remove the side panel from the tab registry entirely. The concept of "hide"—making the side panel inactive but not removing it—could be considered for future enhancements.

3. As was discussed briefly in the last call, the behaviour if both windowId and tabId and if a global side panel is visible on the given tabId. Why should it close the sidePanel for all tabs instead of simply throwing an exception? The intention of the developer is to close it for a specific tab. Closing the global sidePanel can be an unrequested side-effect. If an exception is thrown, a developer can always call close without a tabId to get this kind of behaviour. Yet it seems this should be optional, not enforced.

What I thought was -

1. If a developer wants to close the side panel for a specific tab, they should provide the tabId. This action should only affect the tab-specific side panel on that particular tab.
2. If a developer wants to remove all side panels from a specific tab—regardless of whether they are global or tab-specific—they should provide both windowId and tabId.
   @oliverdunk WDYT?

[oliverdunk]

2. If a developer wants to remove all side panels from a specific tab—regardless of whether they are global or tab-specific—they should provide both windowId and tabId.

If tabId is specified, I don't think we should change behavior (other than basic validation that they match) depending on whether windowId is present. That would conflict with other APIs like sidePanel.open() where windowId is currently ignored if tabId is set.

If there is a global panel open, and you call close() with a tabId, to me it feels like the best option is to match the behavior of the user clicking the close icon in the UI. With that in mind, we would close the global panel everywhere. I feel less strongly on this though and think we could do whatever there is most alignment on.

@kiaraarose Do you have a preference from the Safari side?

[kiaraarose]

@kiaraarose Do you have a preference from the Safari side?

I agree with @carlosjeurissen that the behavior of closing a global sidePanel for all tabs if both windowId and tabId is a bit odd. If the intent is to close a global side panel, then not specifying the tabId would make sense. I can follow up with a dev who hacked on this for Safari (as a project, not shipped) to see they align.

Update: For Safari, we agree that having the sidePanel close for all tabs in this scenario wouldn't be ideal. I think an error for this case is sufficient.

[oliverdunk]

Update: For Safari, we agree that having the sidePanel close for all tabs in this scenario wouldn't be ideal. I think an error for this case is sufficient.

Thanks for following up. To confirm:

• If only tabId is specified, we can still close tab specific side panels. We don't need to require windowId.
• If tabId is specified, but the open side panel for that tab is a global side panel, throw an error.

Is that correct?

Also, an additional question: If you try to open a side panel for a tabId, but you only have a global side panel, should we also throw an error? I expect so but would want to check with Chrome folk as this would be a breaking change we would need to make.