Proposal: Add tabGroups.tabGroup.shared #761
Conversation
add proposal.
Create tab_group_shared_state.md
Co-authored-by: Oliver Dunk <oliver@oliverdunk.com>
Co-authored-by: Oliver Dunk <oliver@oliverdunk.com>
Co-authored-by: Timothy Hatcher <timothy@hatcher.name>
There was a problem hiding this comment.
That which has been written looks good, with minor editorial suggestions applied.
During the meeting where this proposal was discussed, I said that it looks good on the basis that it is just exposing information, and not managing groups (see meeting notes quoted below). Assuming that it is still read-only, this proposal looks good. If in the meantime you have added support for updating shared state, then I'd like to see some more details on that in the proposal.
webextensions/_minutes/2025-01-30-wecg.md
Lines 55 to 64 in a1f7c35
| ### Existing Workarounds | ||
|
|
||
| Extensions developers currently need to rely on error handling in order to handle issues that arise from restrictions on "saved and synced" groups. These will also apply, and more restrictions may be | ||
| put in place for "shared" groups |
There was a problem hiding this comment.
| put in place for "shared" groups | |
| put in place for "shared" groups. |
|
|
||
| ### Open Web API | ||
|
|
||
| the tabGroups functionality is purely a browser feature, which is why we only expose this information through the extensions API |
There was a problem hiding this comment.
| the tabGroups functionality is purely a browser feature, which is why we only expose this information through the extensions API | |
| The tabGroups functionality is purely a browser feature, which is why we only expose this information through the extensions API. |
|
|
||
| ## Implementation Notes | ||
|
|
||
| Other browser vendors have similar implementations of groups, however im not currently aware of any implementation of this shared state exposure for extensions. |
There was a problem hiding this comment.
| Other browser vendors have similar implementations of groups, however im not currently aware of any implementation of this shared state exposure for extensions. | |
| Other browser vendors have similar implementations of groups, however I'm not currently aware of any implementation of this shared state exposure for extensions. |
| the `queryInfo` parameter will accept a new field `shared bool optional` | ||
| When provided the tab groups query will filter based on the shared states of the group. | ||
| [browser.tabGroups.onUpdated](https://developer.chrome.com/docs/extensions/reference/api/tabGroups#event-onUpdated) | ||
| a method that is currently fired when a group is udated, will also fire when the group's shared state changes. |
There was a problem hiding this comment.
| a method that is currently fired when a group is udated, will also fire when the group's shared state changes. | |
| an event that is currently fired when a group is updated, will also fire when the group's shared state changes. |
| a method that is currently fired when a group is udated, will also fire when the group's shared state changes. | ||
| ### Behavior | ||
|
|
||
| Browsers may place browser-specific restrictions on shared groups for security and privacy purposes. This is not limited to the `tabGroups` API and could extend to `browser.tabs` and other related API surfaces. The restriction would result in an error that "the action can not be performed due to the object being in a shared state." or a similar error message. |
There was a problem hiding this comment.
Is this vaguely phrased description meant to rule out the modification of shared state via tabGroups.update? And maybe even preventing the move of groups from tabGroups.move? It is open for interpretation right now.
proposal introducing shared state. see issue #749