From 4023e11890d1d3371010926251263970ee9cbeb0 Mon Sep 17 00:00:00 2001 From: Rrishik <167525753+rishikramena-ms@users.noreply.github.com> Date: Tue, 11 Mar 2025 18:28:57 +0530 Subject: [PATCH 01/11] Create sidepanel_events.md Partial draft --- proposals/sidepanel_events.md | 226 ++++++++++++++++++++++++++++++++++ 1 file changed, 226 insertions(+) create mode 100644 proposals/sidepanel_events.md diff --git a/proposals/sidepanel_events.md b/proposals/sidepanel_events.md new file mode 100644 index 00000000..67caf19a --- /dev/null +++ b/proposals/sidepanel_events.md @@ -0,0 +1,226 @@ +# Proposal: New OnClosed and OnOpened events for the sidePanel API + +** How to Use This Template ** + +See [Proposal Process](proposal_process.md) for the detailed process on how to +propose new APIs and use this template. Each section includes instructions on +what to include. Delete the instructions for a given section once it's filled +out. Remove this section once the template is filled out. + +**Summary** + +Proposal to introduce two new sidePanel lifecycle events that will help developers manage the lifecycle of their extensions + +**Document Metadata** + +**Author:** [rishikramena-ms](https://github.com/rishikramena-ms) + +**Sponsoring Browser:** Microsoft Edge + +**Contributors:** <other contributors emails or GitHub handles> + +**Created:** 2025-03-11 +**Related Issues:** [#752](https://github.com/w3c/webextensions/issues/752) + +## Motivation + +### Objective + +Create new lifecycle events for the chrome.sidPanel API. + +- `chrome.sidePanel.onOpened` +- `chrome.sidePanel.onClosed` + +These events aim to provide developers with better control and management of the side panel's lifecycle, enabling more efficient resource allocation and improved user experience. By implementing these events, developers can: +- **Monitor Side Panel Activity**: Track when the side panel is opened or closed to optimize performance and resource usage. +- **Enhance User Interactions**: Create more responsive and dynamic extensions that react to the side panel's state changes. +- **Improve Extension Functionality**: Allow extensions to perform specific actions when the side panel is opened or closed, such as saving state or cleaning up resources. + +#### Use Cases + +- Resource Management: + - Objective: Optimize resource usage by loading heavy resources only when the side panel is opened. + - Example: An extension that displays real-time data can start fetching data only when the side panel is opened and stop when it is closed, reducing unnecessary network and CPU usage. + +- User Experience Enhancement: + - Objective: Improve user interactions by providing context-specific content or actions. + - Example: An extension that offers contextual help can display relevant tips or tutorials when the side panel is opened, enhancing the user's experience based on their current activity. + +- State Preservation: + - Objective: Save the state of the side panel to maintain continuity between sessions. + - Example: An extension that allows users to take notes can save the current note when the side panel is closed and restore it when reopened, ensuring no data is lost. + +- Dynamic Content Updates: + - Objective: Update content dynamically based on the side panel's visibility. + - Example: An extension that shows notifications can refresh the list of notifications each time the side panel is opened, ensuring the user always sees the most recent updates. + +- Security and Privacy: + - Objective: Enhance security by clearing sensitive information when the side panel is closed. + - Example: An extension that handles sensitive data, such as passwords or personal information, can clear this data from the side panel when it is closed to prevent unauthorized access. + +- Custom Analytics: + - Objective: Collect usage data to understand how users interact with the side panel. + - Example: An extension can log events when the side panel is opened or closed to gather insights into user behavior and improve future versions of the extension. + +### Known Consumers + +The need for lifecycle events have been expressed by many extension developers. The initial discussion was also started by an extension developer ([link](https://github.com/w3c/webextensions/issues/517)). +There have been many workarounds tried by extension developers to get the state change information for the side panel UI for extensions: +A few of them are listed below: +- https://groups.google.com/a/chromium.org/g/chromium-extensions/c/o1_-Su6DkCI +- https://medium.com/@latzikatz/chrome-side-panel-simulate-close-event-c76081f53b97 + + +## Specification + +### Schema + +```ts +namespace sidePanel { + interface Events { + // Fired when a sidePanel hosted by an extension is triggered to open. + static void onOpened( + addListener(callback: () => void): void; + removeListener(callback: () => void): void; + ) + + // Fired when a sidePanel hosted by an extension is triggered to close. + static void onClosed( + addListener(callback: () => void): void; + removeListener(callback: () => void): void; + ) + } + + // Reason for the side panel open trigger + export type onOpenedReason = 'user-action' | +' + +``` + + + + + +Include your API schema here (preferably with a TypeScript interface). If you +are adding new functionality or fields to an existing method, please be sure to +call out explicitly what has changed. + +A few notes: + +* Extension APIs are almost always asynchronous. In most browsers, extensions + run in a separate child process for security purposes. Anything that cannot + be resolved directly in a child process must be asynchronous, and even if + something can be done in a child process today, it should frequently be + asynchronous to prevent future breakage if we move something to the parent + process. +* Failures should be indicated by either synchronously throwing an error + (rare) or rejecting the returned promise. (Note that in legacy versions, + this will populate + [chrome.runtime.lastError](https://developer.chrome.com/extensions/runtime#property-lastError).) + Do not provide another mechanism of indicating failure (e.g., don't accept + a failure callback). +* When practical, prefer accepting objects for input parameters. This allows + us to expand APIs in the future in a non-breaking change by adding + additional optional properties. Even if you currently only accept one + property, it often makes sense to wrap this in an object. + +### Behavior + +Describe the behavior of the new API if there is anything that is not +immediately obvious from the schema above. Include descriptions of: + +* Behavior on the newly-introduced types and methods. +* Impacted behavior on existing API methods and surfaces, if any. + +This does not (yet) need to follow strict spec language; however, the more clear +you can be the better. This helps reduce the number of questions that may arise +during the API review as well as ensure browsers are able to align with one +another. + +You may add subsections (e.g., `#### Behavior Section 1` and +`#### Behavior Section 2`) as appropriate to aid in readbility. + +### New Permissions + +| Permission Added | Suggested Warning | +| ---------------- | ----------------- | +| New Permission 1 | Add a proposed warning string for the permission. If there should be no warning, provide justification as to why. Browser vendors can ultimately choose if there should be a warning and what it should be independently, but this can be useful to define especially if it has implications for the likelihood this proposal will succeed or be useful to developers. | + +Document any new permission added by this API. Permissions are frequently the +same as the API itself, e.g. the `browser.storage` API has the permission +"storage". + +If this is a new API, it should add a new permission. A new permission does +_not_ always require a new permission warning (though it should frequently have +one). Adding a permission allows us to statically analyze extensions with +greater accuracy, and avoid exposing unnecessary APIs. + +If this is a modification to an existing API, it _may_ require a new permission +if the capabilities it adds are significantly different than the existing +functionality in the API, and not already covered by the permission warning. +Note that this is generally an indication that this might be better as a new +API than a modification to an existing API. If no new permission is needed, +note why this falls within the current bounds of the API's capabilities. + +### Manifest File Changes + +Document if your API will require additional manifest fields to be added or +modified (other than a new permission), and what they will do. If non-trivial, +describe the validation and error handling. When a failure is not critical, +prefer a soft warning over a hard error. Hard errors will prevent the extension +from loading, which makes it more challenging to change or expand behavior in +the future. + +If there are no new manifest fields, indicate so here. + +## Security and Privacy + +### Exposed Sensitive Data + +Document any sensitive data or personally-identifiable information the API +exposes to the extension. + +### Abuse Mitigations + +Extension APIs are very frequently powerful and scary (which is one of the +primary reasons they cannot be exposed to the open web). Highlight any ways +this API could be abused by extensions using it. These should describe ways +that the API could be potentially abused that are _not_ bugs in the browser. +(For instance, stealing PII that is provided through the API is not a bug in +the browser, but is an avenue for abuse.) + +Describe how these scenarios will be mitigated. Examples include restricting +based on user action, increased attribution, visual disclosure to the user, +etc. + +### Additional Security Considerations + +Highlight any additional security considerations in the design of this API. +Consider process sandboxing, any input that needs to be sanitized, what can +happen in the case of a compromised process, and other potential attack +vectors. + +## Alternatives + +### Existing Workarounds + +Describe any workarounds that exist today. If this API did not exist, what +approach could developers take to solve the same use cases? + +### Open Web API + +Extensions are designed to be "The Web + More", not an alternative to the web. +Additionally, an Open Web API is generally preferred when possible, because +they allow the utility to be shared by extensions, websites, Progressive Web +Apps, and more. + +Describe why this API does not belong on the open web. + +## Implementation Notes + +If there are any significant notes on implementation that are relevant across +browsers, please indicate them here. (Feel free to add more sections.) + +## Future Work + +Highlight any planned or prospective future work. From 5eeb24b35bba899c7433f1fffc3ea68c4053edd1 Mon Sep 17 00:00:00 2001 From: Rrishik <167525753+rishikramena-ms@users.noreply.github.com> Date: Tue, 11 Mar 2025 23:46:47 +0530 Subject: [PATCH 02/11] Update sidepanel_events.md Added the remaining sections. --- proposals/sidepanel_events.md | 145 ++++++++-------------------------- 1 file changed, 31 insertions(+), 114 deletions(-) diff --git a/proposals/sidepanel_events.md b/proposals/sidepanel_events.md index 67caf19a..1fa40d2c 100644 --- a/proposals/sidepanel_events.md +++ b/proposals/sidepanel_events.md @@ -1,12 +1,5 @@ # Proposal: New OnClosed and OnOpened events for the sidePanel API -** How to Use This Template ** - -See [Proposal Process](proposal_process.md) for the detailed process on how to -propose new APIs and use this template. Each section includes instructions on -what to include. Delete the instructions for a given section once it's filled -out. Remove this section once the template is filled out. - **Summary** Proposal to introduce two new sidePanel lifecycle events that will help developers manage the lifecycle of their extensions @@ -17,9 +10,10 @@ Proposal to introduce two new sidePanel lifecycle events that will help develope **Sponsoring Browser:** Microsoft Edge -**Contributors:** <other contributors emails or GitHub handles> +**Contributors:** **Created:** 2025-03-11 + **Related Issues:** [#752](https://github.com/w3c/webextensions/issues/752) ## Motivation @@ -75,152 +69,75 @@ A few of them are listed below: ### Schema -```ts +```Typescript namespace sidePanel { + // Reason for the side panel open trigger + enum onOpenedReason { + USER_ACTION, + PROGRAMMATIC + } + enum onClosedReason { + USER_ACTION, + PROGRAMMATIC, + NEW_SIDE_PANEL_OPENED + } + interface Events { // Fired when a sidePanel hosted by an extension is triggered to open. static void onOpened( - addListener(callback: () => void): void; - removeListener(callback: () => void): void; + addListener(callback: (reason: onOpenedReason) => void): void; + removeListener(callback: (reason: onOpenedReason) => void): void; ) // Fired when a sidePanel hosted by an extension is triggered to close. static void onClosed( - addListener(callback: () => void): void; - removeListener(callback: () => void): void; + addListener(callback: (reason: onClosedReason) => void): void; + removeListener(callback: (reason: onClosedReason) => void): void; ) } - - // Reason for the side panel open trigger - export type onOpenedReason = 'user-action' | -' - ``` - - - - -Include your API schema here (preferably with a TypeScript interface). If you -are adding new functionality or fields to an existing method, please be sure to -call out explicitly what has changed. - -A few notes: - -* Extension APIs are almost always asynchronous. In most browsers, extensions - run in a separate child process for security purposes. Anything that cannot - be resolved directly in a child process must be asynchronous, and even if - something can be done in a child process today, it should frequently be - asynchronous to prevent future breakage if we move something to the parent - process. -* Failures should be indicated by either synchronously throwing an error - (rare) or rejecting the returned promise. (Note that in legacy versions, - this will populate - [chrome.runtime.lastError](https://developer.chrome.com/extensions/runtime#property-lastError).) - Do not provide another mechanism of indicating failure (e.g., don't accept - a failure callback). -* When practical, prefer accepting objects for input parameters. This allows - us to expand APIs in the future in a non-breaking change by adding - additional optional properties. Even if you currently only accept one - property, it often makes sense to wrap this in an object. - ### Behavior -Describe the behavior of the new API if there is anything that is not -immediately obvious from the schema above. Include descriptions of: - -* Behavior on the newly-introduced types and methods. -* Impacted behavior on existing API methods and surfaces, if any. - -This does not (yet) need to follow strict spec language; however, the more clear -you can be the better. This helps reduce the number of questions that may arise -during the API review as well as ensure browsers are able to align with one -another. - -You may add subsections (e.g., `#### Behavior Section 1` and -`#### Behavior Section 2`) as appropriate to aid in readbility. +Described as code comments in schema. ### New Permissions -| Permission Added | Suggested Warning | -| ---------------- | ----------------- | -| New Permission 1 | Add a proposed warning string for the permission. If there should be no warning, provide justification as to why. Browser vendors can ultimately choose if there should be a warning and what it should be independently, but this can be useful to define especially if it has implications for the likelihood this proposal will succeed or be useful to developers. | - -Document any new permission added by this API. Permissions are frequently the -same as the API itself, e.g. the `browser.storage` API has the permission -"storage". - -If this is a new API, it should add a new permission. A new permission does -_not_ always require a new permission warning (though it should frequently have -one). Adding a permission allows us to statically analyze extensions with -greater accuracy, and avoid exposing unnecessary APIs. - -If this is a modification to an existing API, it _may_ require a new permission -if the capabilities it adds are significantly different than the existing -functionality in the API, and not already covered by the permission warning. -Note that this is generally an indication that this might be better as a new -API than a modification to an existing API. If no new permission is needed, -note why this falls within the current bounds of the API's capabilities. +No new permissions needed. However, the existing `sidePanel` permission to use the `chrome.sidePanel` API will be needed. ### Manifest File Changes -Document if your API will require additional manifest fields to be added or -modified (other than a new permission), and what they will do. If non-trivial, -describe the validation and error handling. When a failure is not critical, -prefer a soft warning over a hard error. Hard errors will prevent the extension -from loading, which makes it more challenging to change or expand behavior in -the future. - -If there are no new manifest fields, indicate so here. +No manifest file changes. ## Security and Privacy +No new security or privacy concerns are expected to be introduced. + ### Exposed Sensitive Data -Document any sensitive data or personally-identifiable information the API -exposes to the extension. +No sensitive user data exposed. ### Abuse Mitigations -Extension APIs are very frequently powerful and scary (which is one of the -primary reasons they cannot be exposed to the open web). Highlight any ways -this API could be abused by extensions using it. These should describe ways -that the API could be potentially abused that are _not_ bugs in the browser. -(For instance, stealing PII that is provided through the API is not a bug in -the browser, but is an avenue for abuse.) - -Describe how these scenarios will be mitigated. Examples include restricting -based on user action, increased attribution, visual disclosure to the user, -etc. +Since this proposal just adds events to an existing API, we do not see any abusive usage concerns. ### Additional Security Considerations -Highlight any additional security considerations in the design of this API. -Consider process sandboxing, any input that needs to be sanitized, what can -happen in the case of a compromised process, and other potential attack -vectors. +None. ## Alternatives ### Existing Workarounds - -Describe any workarounds that exist today. If this API did not exist, what -approach could developers take to solve the same use cases? - +- https://groups.google.com/a/chromium.org/g/chromium-extensions/c/o1_-Su6DkCI +- https://medium.com/@latzikatz/chrome-side-panel-simulate-close-event-c76081f53b97 ### Open Web API -Extensions are designed to be "The Web + More", not an alternative to the web. -Additionally, an Open Web API is generally preferred when possible, because -they allow the utility to be shared by extensions, websites, Progressive Web -Apps, and more. - -Describe why this API does not belong on the open web. +Not applicable to the open web. ## Implementation Notes -If there are any significant notes on implementation that are relevant across -browsers, please indicate them here. (Feel free to add more sections.) +N/A ## Future Work -Highlight any planned or prospective future work. +N/A From 2e5a8e1a8da23523f861cab4ef9ba69bbdec106a Mon Sep 17 00:00:00 2001 From: Rrishik <167525753+rishikramena-ms@users.noreply.github.com> Date: Wed, 12 Mar 2025 10:49:36 +0530 Subject: [PATCH 03/11] Update sidepanel_events.md --- proposals/sidepanel_events.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/proposals/sidepanel_events.md b/proposals/sidepanel_events.md index 1fa40d2c..36eaeff8 100644 --- a/proposals/sidepanel_events.md +++ b/proposals/sidepanel_events.md @@ -71,11 +71,12 @@ A few of them are listed below: ```Typescript namespace sidePanel { - // Reason for the side panel open trigger + // Reason for the side panel open trigger. enum onOpenedReason { USER_ACTION, PROGRAMMATIC } + // Reason for the side panel close trigger. enum onClosedReason { USER_ACTION, PROGRAMMATIC, From 88a4b902c5075ce189226b584d923b1909cc9ce4 Mon Sep 17 00:00:00 2001 From: Rrishik <167525753+rishikramena-ms@users.noreply.github.com> Date: Wed, 12 Mar 2025 16:18:44 +0530 Subject: [PATCH 04/11] Update sidepanel_events.md Updated schema: - added PanelInfo - Removed reasons Removed un-asked use cases Elaborated on the workarounds Added points to the open discussions --- proposals/sidepanel_events.md | 86 ++++++++++++++++++++--------------- 1 file changed, 49 insertions(+), 37 deletions(-) diff --git a/proposals/sidepanel_events.md b/proposals/sidepanel_events.md index 36eaeff8..9b669bc7 100644 --- a/proposals/sidepanel_events.md +++ b/proposals/sidepanel_events.md @@ -1,8 +1,8 @@ -# Proposal: New OnClosed and OnOpened events for the sidePanel API +# Proposal: New onClosed and onOpened events for the sidePanel API **Summary** -Proposal to introduce two new sidePanel lifecycle events that will help developers manage the lifecycle of their extensions +Proposal to introduce two new lifecycle events that will help developers manage the lifecycle of the side panel of their extensions **Document Metadata** @@ -14,13 +14,13 @@ Proposal to introduce two new sidePanel lifecycle events that will help develope **Created:** 2025-03-11 -**Related Issues:** [#752](https://github.com/w3c/webextensions/issues/752) +**Related Issues:** [#752](https://github.com/w3c/webextensions/issues/752), [#517](https://github.com/w3c/webextensions/issues/517) ## Motivation ### Objective -Create new lifecycle events for the chrome.sidPanel API. +Create new lifecycle events for the chrome.sidePanel API. - `chrome.sidePanel.onOpened` - `chrome.sidePanel.onClosed` @@ -32,10 +32,6 @@ These events aim to provide developers with better control and management of the #### Use Cases -- Resource Management: - - Objective: Optimize resource usage by loading heavy resources only when the side panel is opened. - - Example: An extension that displays real-time data can start fetching data only when the side panel is opened and stop when it is closed, reducing unnecessary network and CPU usage. - - User Experience Enhancement: - Objective: Improve user interactions by providing context-specific content or actions. - Example: An extension that offers contextual help can display relevant tips or tutorials when the side panel is opened, enhancing the user's experience based on their current activity. @@ -44,14 +40,6 @@ These events aim to provide developers with better control and management of the - Objective: Save the state of the side panel to maintain continuity between sessions. - Example: An extension that allows users to take notes can save the current note when the side panel is closed and restore it when reopened, ensuring no data is lost. -- Dynamic Content Updates: - - Objective: Update content dynamically based on the side panel's visibility. - - Example: An extension that shows notifications can refresh the list of notifications each time the side panel is opened, ensuring the user always sees the most recent updates. - -- Security and Privacy: - - Objective: Enhance security by clearing sensitive information when the side panel is closed. - - Example: An extension that handles sensitive data, such as passwords or personal information, can clear this data from the side panel when it is closed to prevent unauthorized access. - - Custom Analytics: - Objective: Collect usage data to understand how users interact with the side panel. - Example: An extension can log events when the side panel is opened or closed to gather insights into user behavior and improve future versions of the extension. @@ -69,33 +57,38 @@ A few of them are listed below: ### Schema -```Typescript +```typescript namespace sidePanel { - // Reason for the side panel open trigger. - enum onOpenedReason { - USER_ACTION, - PROGRAMMATIC - } - // Reason for the side panel close trigger. - enum onClosedReason { - USER_ACTION, - PROGRAMMATIC, - NEW_SIDE_PANEL_OPENED - } + + // An object that represents the side panel info. This is used for passing + // the information of the side panel context to the event listeners. + dictionary PanelInfo { + // The window associated with the side panel. + long? windowId; + + // The tab associated with the side panel. This is only set if there is a + // tab-specific panel. + long? tabId; + + // The path to the side panel HTML file in use. + DOMString? path; + }; interface Events { // Fired when a sidePanel hosted by an extension is triggered to open. static void onOpened( - addListener(callback: (reason: onOpenedReason) => void): void; - removeListener(callback: (reason: onOpenedReason) => void): void; - ) + addListener(callback: (options: PanelInfo) => void): void; + hasListener(callback: (options: PanelInfo) => void): void; + removeListener(callback: (options: PanelInfo) => void): void; + ); // Fired when a sidePanel hosted by an extension is triggered to close. static void onClosed( - addListener(callback: (reason: onClosedReason) => void): void; - removeListener(callback: (reason: onClosedReason) => void): void; - ) - } + addListener(callback: (options: PanelInfo) => void): void; + hasListener(callback: (options: PanelInfo) => void): void; + removeListener(callback: (options: PanelInfo) => void): void; + ); + }; ``` ### Behavior @@ -129,6 +122,9 @@ None. ## Alternatives ### Existing Workarounds + +Developers are using the runtime.connect() method to create a long lived channed from the side panel script and listening to the onDisconnect event from the service worker. +References: - https://groups.google.com/a/chromium.org/g/chromium-extensions/c/o1_-Su6DkCI - https://medium.com/@latzikatz/chrome-side-panel-simulate-close-event-c76081f53b97 ### Open Web API @@ -137,8 +133,24 @@ Not applicable to the open web. ## Implementation Notes -N/A +### Open for discussions: +- Should we also add onClosedReasons which can be something + ```typescript + namespace sidePanel { + // Reason for the side panel open trigger. + enum onOpenedReason { + USER_ACTION, + PROGRAMMATIC + } + // Reason for the side panel close trigger. + enum onClosedReason { + USER_ACTION, + PROGRAMMATIC, + NEW_SIDE_PANEL_OPENED + } + } + ``` +- Would adding onHidden, onShown or onVisibilityChanged events for side panel extensions make sense too? ## Future Work -N/A From c8f431ea62782122165036b3bef224e0aa31cf2c Mon Sep 17 00:00:00 2001 From: Rrishik <167525753+rishikramena-ms@users.noreply.github.com> Date: Wed, 12 Mar 2025 16:20:23 +0530 Subject: [PATCH 05/11] Update sidepanel_events.md Updated workarounds --- proposals/sidepanel_events.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/sidepanel_events.md b/proposals/sidepanel_events.md index 9b669bc7..dc53422f 100644 --- a/proposals/sidepanel_events.md +++ b/proposals/sidepanel_events.md @@ -123,7 +123,7 @@ None. ### Existing Workarounds -Developers are using the runtime.connect() method to create a long lived channed from the side panel script and listening to the onDisconnect event from the service worker. +Developers are using the `runtime.connect()` method to create a long lived channed from the side panel script and listening to the `onDisconnect` event from the service worker. References: - https://groups.google.com/a/chromium.org/g/chromium-extensions/c/o1_-Su6DkCI - https://medium.com/@latzikatz/chrome-side-panel-simulate-close-event-c76081f53b97 From c627cfe7c4e5706471bd0436fb22d9fb323b2d80 Mon Sep 17 00:00:00 2001 From: Rrishik <167525753+rishikramena-ms@users.noreply.github.com> Date: Wed, 12 Mar 2025 16:47:45 +0530 Subject: [PATCH 06/11] Update sidepanel_events.md Updated reasons in open discussions. --- proposals/sidepanel_events.md | 32 ++++++++++++++++++++++++-------- 1 file changed, 24 insertions(+), 8 deletions(-) diff --git a/proposals/sidepanel_events.md b/proposals/sidepanel_events.md index dc53422f..2f5bffbd 100644 --- a/proposals/sidepanel_events.md +++ b/proposals/sidepanel_events.md @@ -60,18 +60,32 @@ A few of them are listed below: ```typescript namespace sidePanel { - // An object that represents the side panel info. This is used for passing - // the information of the side panel context to the event listeners. - dictionary PanelInfo { + // An object that represents the side panel open info. This is used for + // passing the information of the side panel context to the event listeners. + dictionary PanelOpenInfo { // The window associated with the side panel. - long? windowId; + long windowId; // The tab associated with the side panel. This is only set if there is a // tab-specific panel. long? tabId; // The path to the side panel HTML file in use. - DOMString? path; + DOMString path; + }; + + // An object that represents the side panel close info. This is used for + // passing the information of the side panel context to the event listeners. + dictionary PanelClosInfo { + // The window associated with the side panel. + long windowId; + + // The tab associated with the side panel. This is only set if there is a + // tab-specific panel. + long? tabId; + + // The path to the side panel HTML file in use. + DOMString path; }; interface Events { @@ -134,23 +148,25 @@ Not applicable to the open web. ## Implementation Notes ### Open for discussions: -- Should we also add onClosedReasons which can be something +- Should we also have trigger reasons for the onClosed and onOpened events? ```typescript namespace sidePanel { // Reason for the side panel open trigger. enum onOpenedReason { USER_ACTION, - PROGRAMMATIC + PROGRAMMATIC, } // Reason for the side panel close trigger. enum onClosedReason { USER_ACTION, PROGRAMMATIC, - NEW_SIDE_PANEL_OPENED + NEW_SIDE_PANEL_OPENED, + TAB_CLOSED } } ``` - Would adding onHidden, onShown or onVisibilityChanged events for side panel extensions make sense too? ## Future Work +- Providing granualar controls for attaching listeners for tab specific or path specific side panels. From d3d959c294ec6994d078dd7a8e95fb576f27e09c Mon Sep 17 00:00:00 2001 From: Rrishik <167525753+rishikramena-ms@users.noreply.github.com> Date: Wed, 12 Mar 2025 17:14:48 +0530 Subject: [PATCH 07/11] Update sidepanel_events.md --- proposals/sidepanel_events.md | 24 +++++++++++------------- 1 file changed, 11 insertions(+), 13 deletions(-) diff --git a/proposals/sidepanel_events.md b/proposals/sidepanel_events.md index 2f5bffbd..c84fc4d9 100644 --- a/proposals/sidepanel_events.md +++ b/proposals/sidepanel_events.md @@ -25,10 +25,7 @@ Create new lifecycle events for the chrome.sidePanel API. - `chrome.sidePanel.onOpened` - `chrome.sidePanel.onClosed` -These events aim to provide developers with better control and management of the side panel's lifecycle, enabling more efficient resource allocation and improved user experience. By implementing these events, developers can: -- **Monitor Side Panel Activity**: Track when the side panel is opened or closed to optimize performance and resource usage. -- **Enhance User Interactions**: Create more responsive and dynamic extensions that react to the side panel's state changes. -- **Improve Extension Functionality**: Allow extensions to perform specific actions when the side panel is opened or closed, such as saving state or cleaning up resources. +These events aim to provide developers with better control and management of the side panel's lifecycle. #### Use Cases @@ -76,7 +73,7 @@ namespace sidePanel { // An object that represents the side panel close info. This is used for // passing the information of the side panel context to the event listeners. - dictionary PanelClosInfo { + dictionary PanelCloseInfo { // The window associated with the side panel. long windowId; @@ -91,16 +88,16 @@ namespace sidePanel { interface Events { // Fired when a sidePanel hosted by an extension is triggered to open. static void onOpened( - addListener(callback: (options: PanelInfo) => void): void; - hasListener(callback: (options: PanelInfo) => void): void; - removeListener(callback: (options: PanelInfo) => void): void; + addListener(callback: (info: PanelOpenInfo) => void): void; + hasListener(callback: (info: PanelOpenInfo) => void): void; + removeListener(callback: (info: PanelOpenInfo) => void): void; ); // Fired when a sidePanel hosted by an extension is triggered to close. static void onClosed( - addListener(callback: (options: PanelInfo) => void): void; - hasListener(callback: (options: PanelInfo) => void): void; - removeListener(callback: (options: PanelInfo) => void): void; + addListener(callback: (info: PanelCloseInfo) => void): void; + hasListener(callback: (info: PanelCloseInfo) => void): void; + removeListener(callback: (info: PanelCloseInfo) => void): void; ); }; ``` @@ -108,6 +105,7 @@ namespace sidePanel { ### Behavior Described as code comments in schema. +Additionally, for spanning mode extensions in Incognito, these events will be ### New Permissions @@ -148,7 +146,7 @@ Not applicable to the open web. ## Implementation Notes ### Open for discussions: -- Should we also have trigger reasons for the onClosed and onOpened events? +- Should we also have trigger reasons for the onClosed and onOpened events? An sample schema for the reasons is given below. ```typescript namespace sidePanel { // Reason for the side panel open trigger. @@ -168,5 +166,5 @@ Not applicable to the open web. - Would adding onHidden, onShown or onVisibilityChanged events for side panel extensions make sense too? ## Future Work -- Providing granualar controls for attaching listeners for tab specific or path specific side panels. +- Providing granualar controls for attaching listeners for tab-specific or path-specific side panels. From 94348f48aea0ba387ee440b31805e7118ddef2fc Mon Sep 17 00:00:00 2001 From: Rrishik <167525753+rishikramena-ms@users.noreply.github.com> Date: Wed, 12 Mar 2025 17:17:46 +0530 Subject: [PATCH 08/11] Update sidepanel_events.md Fixed typos --- proposals/sidepanel_events.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/proposals/sidepanel_events.md b/proposals/sidepanel_events.md index c84fc4d9..ff31ce7a 100644 --- a/proposals/sidepanel_events.md +++ b/proposals/sidepanel_events.md @@ -135,7 +135,7 @@ None. ### Existing Workarounds -Developers are using the `runtime.connect()` method to create a long lived channed from the side panel script and listening to the `onDisconnect` event from the service worker. +Developers are using the `runtime.connect()` method to create a long lived channel from the side panel script and listening to the `onDisconnect` event from the service worker. References: - https://groups.google.com/a/chromium.org/g/chromium-extensions/c/o1_-Su6DkCI - https://medium.com/@latzikatz/chrome-side-panel-simulate-close-event-c76081f53b97 @@ -146,7 +146,7 @@ Not applicable to the open web. ## Implementation Notes ### Open for discussions: -- Should we also have trigger reasons for the onClosed and onOpened events? An sample schema for the reasons is given below. +- Should we also have trigger reasons for the onClosed and onOpened events? A sample schema for the reasons is given below. ```typescript namespace sidePanel { // Reason for the side panel open trigger. @@ -166,5 +166,5 @@ Not applicable to the open web. - Would adding onHidden, onShown or onVisibilityChanged events for side panel extensions make sense too? ## Future Work -- Providing granualar controls for attaching listeners for tab-specific or path-specific side panels. +- Providing granular controls for attaching listeners for tab-specific or path-specific side panels. From 57239c5fa450b509ec617e2570d7bc5bc2a4e499 Mon Sep 17 00:00:00 2001 From: Rrishik <167525753+rishikramena-ms@users.noreply.github.com> Date: Wed, 12 Mar 2025 17:36:30 +0530 Subject: [PATCH 09/11] Update sidepanel_events.md Moved content from future work to Open discussions. --- proposals/sidepanel_events.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/proposals/sidepanel_events.md b/proposals/sidepanel_events.md index ff31ce7a..ff360c5e 100644 --- a/proposals/sidepanel_events.md +++ b/proposals/sidepanel_events.md @@ -105,7 +105,6 @@ namespace sidePanel { ### Behavior Described as code comments in schema. -Additionally, for spanning mode extensions in Incognito, these events will be ### New Permissions @@ -164,7 +163,7 @@ Not applicable to the open web. } ``` - Would adding onHidden, onShown or onVisibilityChanged events for side panel extensions make sense too? +- Should we providing granular controls for attaching listeners for tab-specific or path-specific side panels. ## Future Work -- Providing granular controls for attaching listeners for tab-specific or path-specific side panels. From 19e63c40b0ff0dba5e09fcdcd7bc706b29b1652e Mon Sep 17 00:00:00 2001 From: Rrishik <167525753+rishikramena-ms@users.noreply.github.com> Date: Wed, 12 Mar 2025 17:37:30 +0530 Subject: [PATCH 10/11] Update sidepanel_events.md --- proposals/sidepanel_events.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/sidepanel_events.md b/proposals/sidepanel_events.md index ff360c5e..a4e2c1b5 100644 --- a/proposals/sidepanel_events.md +++ b/proposals/sidepanel_events.md @@ -163,7 +163,7 @@ Not applicable to the open web. } ``` - Would adding onHidden, onShown or onVisibilityChanged events for side panel extensions make sense too? -- Should we providing granular controls for attaching listeners for tab-specific or path-specific side panels. +- Should we provide granular controls for attaching listeners for tab-specific or path-specific side panels. ## Future Work From 7e89fbce783f74e247f4ee99786de9801f75a4dc Mon Sep 17 00:00:00 2001 From: Rrishik <167525753+rishikramena-ms@users.noreply.github.com> Date: Wed, 12 Mar 2025 23:36:08 +0530 Subject: [PATCH 11/11] removing a use case --- proposals/sidepanel_events.md | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/proposals/sidepanel_events.md b/proposals/sidepanel_events.md index a4e2c1b5..fedeeed0 100644 --- a/proposals/sidepanel_events.md +++ b/proposals/sidepanel_events.md @@ -31,11 +31,7 @@ These events aim to provide developers with better control and management of the - User Experience Enhancement: - Objective: Improve user interactions by providing context-specific content or actions. - - Example: An extension that offers contextual help can display relevant tips or tutorials when the side panel is opened, enhancing the user's experience based on their current activity. - -- State Preservation: - - Objective: Save the state of the side panel to maintain continuity between sessions. - - Example: An extension that allows users to take notes can save the current note when the side panel is closed and restore it when reopened, ensuring no data is lost. + - Example: An extension that offers contextual help can display relevant tips or tutorials when the side panel is opened, enhancing the user's experience based on their current activity. Although this can be achived in other ways, but having a dedicated event will make using it simpler. - Custom Analytics: - Objective: Collect usage data to understand how users interact with the side panel.