Proposal: close() Method for the sidePanel API #837

hharshas · 2025-05-28T15:08:57Z

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.

proposals/sidepanel-close-api.md

dotproto · 2025-05-29T00:50:13Z

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.

proposals/sidepanel-close-api.md

hharshas · 2025-06-05T19:16:37Z

@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.

proposals/sidepanel-close-api.md

carlosjeurissen · 2025-07-03T14:19:06Z

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 API for mv3 #128
We should clarify the difference between hiding vs closing the sidebar and the implications.
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 · 2025-07-03T16:04:17Z

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.

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 -

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.
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 · 2025-07-04T11:51:57Z

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?

The sidePanel.close() method allows extensions to programmatically close the side panel for a specified tabId or windowId. Reference: w3c/webextensions#837 Bug: 403765214 Change-Id: I16b1c05869a1f4707bf107d4eff1d085235b906b Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6638129 Reviewed-by: Devlin Cronin <[email protected]> Commit-Queue: Oliver Dunk <[email protected]> Reviewed-by: Oliver Dunk <[email protected]> Cr-Commit-Position: refs/heads/main@{#1499029}

kiaraarose · 2025-08-14T06:22:54Z

@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 · 2025-09-11T08:54:37Z

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.

oliverdunk · 2025-11-05T15:42:07Z

Hi @kiaraarose / @carlosjeurissen - we have been looking at updating sidePanel.open to remove the fallback to a global panel if tabId is specified but there is no tab-specific panel. However, in testing this breaks many of the popular extensions I tried including Grammarly, Phantom, Sider and QuillBot. With that in mind, it seems like this would be both a non-trivial breaking change and go against the expectations developers seem to naturally have.

Let's plan on discussing next steps at TPAC? Based on this I am once again leaning towards supporting a fallback to the global panel for both the open() and close() methods.

Rob--W · 2025-11-14T05:56:33Z

I'm taking over the review from @zombie on behalf of Mozilla, since I have been actively involved in discussions on the design of sidepanel/sidebar APIs at TPAC 2025. Those meeting notes will be published soon.

carlosjeurissen

The suggested changes apply what has been discussed during TPAC2025. There is one open end:
Should we specify a global side panel will be reopened when closing a contextual one when switching tabs and returning to the tab with contextual side panel? As this is current Chrome behaviour.

carlosjeurissen · 2025-11-20T07:11:41Z

proposals/sidepanel-close-api.md

+- If `windowId` or `tabId` is invalid, rejects with an error.
+- If both `windowId` and `tabId` are provided, the method will verify
+  that the tab belongs to the specified window. If not, it rejects with an error.
+- If both `windowId` and `tabId` are provided:


Suggested change

- If both `windowId` and `tabId` are provided:

- If `tabId` is provided:

Calling only with a tabId should be possible

carlosjeurissen · 2025-11-20T07:13:37Z

proposals/sidepanel-close-api.md

+- If the panel is already closed or does not exist in the given
+  context, the method does nothing.


Suggested change

- If the panel is already closed or does not exist in the given

context, the method does nothing.

Move this to the two different scenarios, in which the method is called with a tabId or without a tabId

carlosjeurissen · 2025-11-20T07:16:00Z

proposals/sidepanel-close-api.md

+    1. If a contextual side panel is visible on the specified `tabId`, it will be closed.
+    2. If a global side panel is visible on the given `tabId`,
+       it will be closed for all tabs in that window, not just the specified tab.


Suggested change

1. If a contextual side panel is visible on the specified `tabId`, it will be closed.

2. If a global side panel is visible on the given `tabId`,

it will be closed for all tabs in that window, not just the specified tab.

1. If no contextual side panel is configured for the specified `tabId`, reject with an error.

2. If the contextual side panel is currently not open, the method does nothing.

3. If the contextual side panel is currently open, it will close the contextual side panel.

carlosjeurissen · 2025-11-20T07:18:22Z

proposals/sidepanel-close-api.md

+    1. If a contextual side panel is visible on the specified `tabId`, it will be closed.
+    2. If a global side panel is visible on the given `tabId`,
+       it will be closed for all tabs in that window, not just the specified tab.
+


Suggested change

- If `tabId` is not provided:

1. If no global side panel is currently open in the window, this method does nothing.

2. If a global side panel is currently open in the window, close just the global side panel.

The sidePanel.close() call with tabId no longer falls back to the global panel. It now exclusively closes tab-specific panels and returns an error if one is not enabled for that tab. Reference: w3c/webextensions#837 Bug: 403765214 Change-Id: I6d4fe1b1f2382a7d81bc2216418c9e4e513f66ef Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7317143 Reviewed-by: Oliver Dunk <[email protected]> Commit-Queue: Oliver Dunk <[email protected]> Reviewed-by: Solomon Kinard <[email protected]> Commit-Queue: Harsh Singh <[email protected]> Cr-Commit-Position: refs/heads/main@{#1566376}

harsh singh added 6 commits May 28, 2025 02:43

change: 1

37ea058

changes: 2

6d34867

changes: 3

419caa5

changes : 4

f9b2fcb

Trigger affiliation recheck

96a097c

Re-Trigger affiliation recheck

255679a

dotproto requested changes May 29, 2025

View reviewed changes

hharshas added 2 commits May 29, 2025 12:54

Internal styling fixes

e0db95e

trailing whitespace

bbb14d3

hharshas requested a review from dotproto May 29, 2025 12:22

oliverdunk mentioned this pull request Jun 4, 2025

Agenda discussion for public meeting on 2025-06-05 #835

Closed

oliverdunk reviewed Jun 5, 2025

View reviewed changes

proposals/sidepanel-close-api.md Outdated Show resolved Hide resolved

change in #use cases

616013b

kiaraarose self-requested a review June 5, 2025 17:51

kiaraarose approved these changes Jun 5, 2025

View reviewed changes

dotproto mentioned this pull request Jun 5, 2025

Publish minutes of 2025-06-05 #841

Merged

carlosjeurissen self-requested a review June 6, 2025 07:10

oliverdunk approved these changes Jun 6, 2025

View reviewed changes

proposals/sidepanel-close-api.md Show resolved Hide resolved

hharshas added 4 commits June 7, 2025 20:22

Update #Behavior

199ab84

Update #Objective

4eb6c07

Update sidepanel-close-api.md

5544257

Update #Behavior

2ff64ff

carlosjeurissen mentioned this pull request Jul 3, 2025

Side Panel API: query position: left/right, close(), and focus(): tab to and from side panel #833

Open

Rob--W mentioned this pull request Jul 31, 2025

Publish minutes of 2025-07-31 meeting #857

Merged

Rob--W requested a review from zombie August 7, 2025 15:37

This was referenced Aug 14, 2025

Agenda discussion for public meeting on 2025-08-14 #858

Closed

Agenda discussion for public meeting on 2025-09-11 #867

Closed

oliverdunk mentioned this pull request Sep 24, 2025

Agenda discussion for public meeting on 2025-09-25 #871

Closed

Rob--W mentioned this pull request Sep 25, 2025

Publish minutes of 2025-09-25 meeting #874

Merged

This was referenced Nov 9, 2025

WECG at TPAC 2025 #843

Closed

Proposal: agree on a unified sidebar API for mv3 #128

Open

Rob--W requested review from Rob--W and removed request for zombie November 14, 2025 05:49

carlosjeurissen suggested changes Nov 20, 2025

View reviewed changes

Rob--W mentioned this pull request Dec 1, 2025

Publish minutes of 2025-11-10 - 2025-11-14 TPAC meetings #923

Merged

	- If both `windowId` and `tabId` are provided:
	- If `tabId` is provided:

		- If the panel is already closed or does not exist in the given
		context, the method does nothing.

+- If `tabId` is not provided:
+. If no global side panel is currently open in the window, this method does nothing.
+. If a global side panel is currently open in the window, close just the global side panel.

Proposal: close() Method for the sidePanel API #837

Are you sure you want to change the base?

Proposal: close() Method for the sidePanel API #837

Uh oh!

Conversation

hharshas commented May 28, 2025

Uh oh!

dotproto left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

dotproto commented May 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

oliverdunk left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

hharshas commented Jun 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

oliverdunk left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

carlosjeurissen commented Jul 3, 2025

Uh oh!

hharshas commented Jul 3, 2025

Uh oh!

oliverdunk commented Jul 4, 2025

Uh oh!

kiaraarose commented Aug 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

oliverdunk commented Sep 11, 2025

Uh oh!

oliverdunk commented Nov 5, 2025

Uh oh!

Rob--W commented Nov 14, 2025

Uh oh!

carlosjeurissen left a comment

Choose a reason for hiding this comment

Uh oh!

carlosjeurissen Nov 20, 2025

Choose a reason for hiding this comment

Uh oh!

carlosjeurissen Nov 20, 2025

Choose a reason for hiding this comment

Uh oh!

carlosjeurissen Nov 20, 2025

Choose a reason for hiding this comment

Uh oh!

carlosjeurissen Nov 20, 2025

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

dotproto commented May 29, 2025 •

edited

Loading

hharshas commented Jun 5, 2025 •

edited

Loading

kiaraarose commented Aug 14, 2025 •

edited

Loading