feat: Support Firefox native tab groups API (issue #5212)#5361
feat: Support Firefox native tab groups API (issue #5212)#5361repparw wants to merge 11 commits into
Conversation
|
Can't test locally right now, but if someone has time, I think it should be mostly done? |
|
thanks for this :) do you know what's causing the formatting changes? it makes it really hard to see what has changed and what is just some whitespace generally I'd be happier if PRs were kept <100 lines of changes so i have some chance to review them. i get that this is a big feature but i suspect bits of it could be terser or split into multiple smaller commits. also, aren't the tests basically pointless? they're just checking if functions are functions. which typescript will already be checking 🤔 |
86058f0 to
1713f53
Compare
|
yeah I think I had a write on save formatter in my nvim config enabled, I'll check that. re tests: fair, I'll remove that lmao |
e085f32 to
b2907bb
Compare
|
the excmds formatting changes seem to be from a change in prettier on the pre-commit hook I think, can recreate by running |
There was a problem hiding this comment.
Pull request overview
This PR adds support for Firefox’s native tab groups API (tabGroups / tabs.group) alongside the existing legacy tab-group implementation backed by browser.sessions.
Changes:
- Add
tabGroupspermission and update WebExtension type definitions to include native tab group APIs. - Extend
src/lib/tab_groups.tswith native tab group detection, color normalization, native implementations of group operations, and a migration helper. - Update tab-group ex-commands to support native groups (including color support, migration, and listing supported colors).
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 7 comments.
| File | Description |
|---|---|
src/manifest.json |
Adds the tabGroups permission required for native tab group APIs. |
src/lib/tab_groups.ts |
Implements native tab group support, color handling, and legacy→native migration logic. |
src/excmds.ts |
Adds/updates tab group commands to use native tab groups when available (create/switch/migrate/colors). |
package.json |
Bumps @types/firefox-webext-browser to a newer version for updated WebExtension typings. |
Comments suppressed due to low confidence (1)
src/manifest.json:145
- Adding the
tabGroupspermission to the required permissions list may prevent installation on Firefox versions that don’t recognize this permission (the code/docs here mention native tab groups being Firefox 137+ whilestrict_min_versionis still 91.1.0). Consider either bumpingstrict_min_versionaccordingly or movingtabGroupsintooptional_permissionsand requesting it only when the native API is available.
"tabGroups",
"webNavigation",
"webRequest",
"webRequestBlocking",
"proxy",
"<all_urls>"
],
"applications": {
"gecko": {
"id": "tridactyl.vim.betas@cmcaine.co.uk",
"strict_min_version": "91.1.0"
}
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
3ce06d4 to
1a8fc9e
Compare
- Add native tab groups support (Firefox 137+) - Feature detection with caching - Error handling with fallback - Color support via :tgroupcreate <name> <color> - :tgroupmigrate and :tgroupcolors commands - Updated @types/firefox-webext-browser to v143.0.0
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
- Use tab's window instead of activeWindowId for setTabTgroup - Await async calls in try/catch for proper error handling - Add Array.isArray check for type safety in migration - Optimize migration: query tabs once and parallelize tab value fetches
Add tabGroups to optional_permissions to avoid installation issues on Firefox versions < 137 that don't recognize this permission. Also update yarn.lock for @types/firefox-webext-browser.
1a8fc9e to
6ccc47b
Compare
bovine3dom
left a comment
There was a problem hiding this comment.
rebased on master with prettier changes to reduce noise
i dunno how i feel about the optional permission. it means that it won't stop people from updating, but in practice i don't know how many people will enable it
i couldn't personally work out how to do so so couldn't even test the new paths 🙃
| "<all_urls>" | ||
| ], | ||
| "optional_permissions": [ | ||
| "tabGroups" |
There was a problem hiding this comment.
if users don't allow this they will fall back to our current groups
we probably need to provide some upgrade wizard that allows them to enable the permission (iirc we can only do it on user actions, i.e. they need to click a button somewhere or use a browser bind. not an excmd) and then migrate their existing groups
which is lame but them's the rules
There was a problem hiding this comment.
I think it's in optional because the required minimum version was very low. (like around 90?)
We could put it with the other permissions and bump minimum req version to 137... I don't think anyone is just not updating their browser anyways?
There was a problem hiding this comment.
"To use this API, an extension must request the "tabGroups" permission in its manifest.json file. The "tabGroups" permission is not shown to users in permission prompts."
If I understand correctly this means they should go to Extensions > Permissions and data after updating?
…fox version to 138.0
|
We could also add an issue to track the chrome API implementation, out of scope for me, but maybe with this as base it's easier |
|
ok, cool, the PR does actually do something now :) first regression is that second one i've seen is that because tab groups aren't actually hidden, please could you test this PR thoroughly against current behaviour? we have like 10-50k active users so even the smallest amount of friction to muscle memory adds up to a lot of sad people we should probably also add some config for people who prefer tridactyl's groups to the native ones |
|
I'll check switch and b in a moment! haven't tested it yet, maybe after fixing this or in the weekend. I didn't use the tridactyl groups so I don't really know what to test for, if you have any other pointers for use-cases/setups, I'm doing all this to have a better way to manip the native groups lmao re config: I was working on the assumption of your comment, do you think we should keep both? at this point shouldn't be too difficult, as we have the check for tabgroups api existing, can change it to check api and config |
|
should |
- tgroupcreate: group ungrouped tabs instead of creating new tab - tgroupcreate: skip tabs.hide/show when using native groups - tgroupmove: skip tabs.hide/show when using native groups
Only show tabs from current group when using native tab groups API to maintain expected 'b' behavior.
|
afaict now's okay. move was also still hiding tabs after moving, changed that too |
|
rename is also not working. fixing that now... |
|
It works right now, at least with the mock data I used for testing, couldn't get old tabgroups into the PR branch's web-ext to try with 'real' data Commited the mock script if you want to test yourself, in a diff commit to easily remove it for merging |
Summary
Integrates Firefox's built-in tab groups (FF 137+) as the backend for Tridactyl's tab group commands.
Closes #5212
Changes
"tabGroups"permission@types/firefox-webext-browserto v143.0.0Key Benefits
New Commands
Migration
Users upgrading from older Firefox versions (pre-137) can migrate their existing tab groups to native groups using:
This converts groups stored in browser.sessions to native Firefox groups. The migration:
Usage Examples
Testing
Notes
hasNativeTabGroups()checks forbrowser.tabs.group