I am quoting Kev Needham from https://blog.mozilla.org/addons/2015/08/21/the-future-of-developing-firefox-add-ons/: "We want to reiterate our commitment to our add-on development community, and will work with you in porting extensions, designing new APIs, and creating innovative new add-ons that make Firefox great." If this is true then Mozilla will need to develop many many apis in order to support Tab Groups (aka Panorama).. if it is not true then it will be impossible to port this extensions which I want to see done and would have been possible with the sdk. Panorama was built as an extension at first (which is how innovative ideas should be created imo), then it was shipped with Firefox (before all of the ux bugs were worked out), then in bug 1221497 someone decided to remove it which was ok because it was still possible to port the feature back to an extension.. and now Kev Needham has hit us with his webextensions plan out of nowhere, but atleast Kev promised to make porting extensions like these possible as stated above. So I would like to know how Mozilla suggests the extension community should go about porting this extension?

FWIW my Tab Groups add-on will probably be the easiest one out of all my add-ons to port to a WebExtension format, since it is the one that least touches/depends on UI modifications. Having said that, it would require some specific APIs of course, although I haven't really looked into what it actually would require yet, and how it would (could) work either myself.

Native.js looks like a bad approach as I describe in bug 1199718, but I am making this bug depend on a resolution of bug 1199718 because other bugs like this one are doing the same.

With Tab Center in Test Pilot, I think the only thing missing is a "tab grouping" API. Assuming that everyone finds Tab Center awesome and clamours for it to merged into mozilla-central which I can hope for because it is great.

Aren't you a bit senior to be spamming the thread? (1) "Tab Center: Display tabs vertically along the side of the screen instead of horizontally along the top of the browser to give you a new way to experience tabbed browsing." [1] How is that germane to Tab Groups? (2) "I think the only thing missing is a "tab grouping" API." [Comment 3] Which is the pith, the raison d'être, of Tab Groups. The only thing missing then from Tab Groups support is Tab Groups support. (3) Test Pilot ejected; chute failed to open. (https://testpilot.firefox.com/, FF 46, Ubuntu 14.04) Exception { message: "", result: 2147746132, name: "NS_ERROR_FACTORY_NOT_REGISTERED", filename: "https://testpilot.firefox.com/stati…", lineNumber: 10, columnNumber: 0, data: null, stack: "ne@https://testpilot.firefox.com/st…" } app.js:9:1328 [998]</<.initialize/<() app.js:9 I see only a blank page. Oddly enough, the page loads in Chrome, but it has only two links, a link to itself and a link to install Firefox, so perhaps Chrome loads a different page. I'll assume for now that Test Pilot is whatever I imagine it to be. (4) about:home is a poor conduit to, well, anything. I don't see the Home page for months at a time, haven't since Firefox could restore tabs on startup. What's wanted is something like developer.mozilla.org's "Was this helpful?" campaign - easy to participate, easy to ignore, hard to dislike because it's so polite - but discreetly placed somewhere in the browser. (5) Reusing an existing product name wasn't very clever. It was a seldom-used survey instrument, wasn't it? The recent press releases have helped reduce the confusion, though. Thank you. I hope you do really want to support Tab Groups as a WebExtension and that this thread was only a target of opportunity. [1] https://blog.mozilla.org/blog/2016/05/10/you-can-help-build-the-future-of-firefox-with-the-new-test-pilot-program/

The Tab Groups extension on AMO is an extraction of the code from mozilla-central and contains XUL and so on. It has multiple features including the ability to go to a user interface and show a list of tabs, drag and drops tabs between different groups a preferences page that provides some options and so on. Which of these features cannot be done as a WebExtension right now? What are we missing that needs implementing? Perhaps you'd like an API to grab a thumbnail of a tab? Perhaps you'd like a specific grouping API that is something like: browser.window.createGroup(groupId, tabIds...) browser.window.switchToGroup(groupId) browser.window.getGroup(groupId) ... and so on. I just made those APIs up. Tree style tabs has more users does this differently by making tabs vertical (cue Vertical Tab) and then allowing one tab to be situated under another. Would that be more useful? Would an API like: browser.tabs.subTab(tabId, tabId) ...be more useful there? This bug is not written in an especially helpful way, I'd like to take it that way by finding out what people need.

(In reply to Andy McKay [:andym] from comment #3) > With Tab Center in Test Pilot, I think the only thing missing is a "tab > grouping" API. I personally don't see anything Tab Center-related that could be of even marginal use, to any grouping-like function. Unless you meant that in a more "With that out of the way, now we can..." sort of thing. > The Tab Groups extension on AMO is an extraction of the code from mozilla-central Not for long. ;) That's irrelevant I know, I just like to tease about Tab Groups 2. > Which of these features cannot be done as a WebExtension right now? What are we missing that needs implementing? Perhaps you'd like an API to grab a thumbnail of a tab? As far as core functionality goes, access to the session is the most important, since that's where the actual grouping resides. Besides that, it would need specific tab-related things (like the thumbnails, yeah definitely), but not absolutely impossible, with some work in both sides of course. However, I completely disagree with an API like you suggested, where the actual grouping resides within Firefox code. From there it's a short step to build an UI to just use it within Firefox itself, which would be better than having functionality split between Firefox code and add-on (WebExtension) code. > This bug is not written in an especially helpful way, I'd like to take it that way by finding out what people need. Agreed. As far as Tab Groups and all my other add-ons go, I have been looking into WebExtensions development lately, putting together a few notions that I will share soon in the mailing list which is probably a better place for discussing it, after I finish TG2, definitely still this month. I'm not sure you'll like them though, I'm not particularly fond of most of my conclusions so far myself. :(

(In reply to Luís Miguel [:quicksaver] from comment #6) > Agreed. As far as Tab Groups and all my other add-ons go, I have been > looking into WebExtensions development lately, putting together a few > notions that I will share soon in the mailing list which is probably a > better place for discussing it, after I finish TG2, definitely still this > month. I'm not sure you'll like them though, I'm not particularly fond of > most of my conclusions so far myself. :( Cool, let's do that then. For the moment until we can get something more we can work with, I'll close those bug.

Enhance your calm, John Spartan. (In reply to Andy McKay [:andym] from comment #3) > What are we missing that needs implementing? (1) Hidden tabs, or hidden windows to serve as latent tabgroups. I favor hidden windows since `chrome.windows` and `chrome.tabs` could be leveraged to create and manage tab groups. A new `hidden` WindowState, a new `hidden_windows` permission, etc. (2) Thumbnails. I favor a thumbnail service that can provide a thumbnail given a URL, because they're already being generated and are useful in more ways than one. URLs in open tabs should all have thumbnails; maybe others. (3) A modal management page that extends over toolbox#navigator-toolbox. Or, expose the stylesheet service so that #navigator-toolbox can be collapsed. I weakly favor a modal management page, perhaps as a tab variant, for its versatility. A page that can overlay both content and chrome, dynamically resize itself, reserve space for itself at an edge of the browser, and revert to a conventional tab as required spans the behavior of Tab Groups, Tab Center, the current `#navigator-toolbox`, Developer Tools, docking toolbars, those nice thumbnails Opera used to show below the tab bar, all of which could be implemented as (hybrid) WebExtensions. I'm sure there are others - Firefox is famous for add-ons that rejigger the chrome. If Tab Center is to be standard Firefox equipment, (4) Expose Tab Center's group management and thumbnails capabilities to other extensions via `runtime.sendMessage/.onMessageExternal` and a well-known extension ID. (After it's refactored into a hybrid WebExtension, of course.) It's the spirit of Maone's "native.js with shared interface", if not the letter. (1) is a must-have; we want to hide tabs, not close them. That can't be done in Chrome. (2) is a should-have; one could cobble around it with `tabs.captureVisibleTab` and `canvas`. (3) is a should-have; the tabs manager could be a conventional tab. Don't be mad, Andy; you were electioneering. Tab Center doesn't support tab groups, uses no WebExtension interfaces, and exposes no interface to WebExtensions.

as for :quicksaver discontinued* his efforts on developing Tab Group, I believe this bug should be reopen for us to keep track of related projects or effort on this welcoming feature. * fasezero.com

Bug 1384515 suggest a API to show/hide specific tabs which would compline 1) from comment #8.

Bug 1246693 suggest a thumbnail generate API which can be use at 2) on comment #8

In bug #1366478 I suggest a slightly different approach to this problem. See-Also: https://bugzilla.mozilla.org/show_bug.cgi?id=1366478

https://addons.mozilla.org/zh-TW/firefox/addon/taborama/ There is a new add-on Taborama from kesselborn, which combine Container with Tab Group approach. However it's still block on Bug 1384515.

Thanks Irvin, I see there is a the same in Chrome. I'll test it there before possibly switching. Also seems there is now an alternative to "Tree Style Tab": https://addons.mozilla.org/fr/firefox/addon/tab-tree/ Did not test it yet. I'll wait FF 57 I guess...

I'd like to point out a novel approach to Tab Groups that many developers aren't aware of, but that thousands of users have found ABSOLUTELY CRITICAL to their workflow. I know there's already a train of thought in this thread, but I ask that you might humor me as I share a concept/paradigm with you. This basic idea blows Panorama out of the water. Have you all ever seen TabGroups Manager? https://addons.mozilla.org/en-US/firefox/addon/tabgroups-manager-revived If you ask browser users, "Why do you want tab groups as a feature?" they typically say, "Because I want a quick and easy way to organize my open tabs into logical named groups so I can work more efficiently. They don't say, "Because I want to jump back and forth between an abstracted Panorama view." Users like me still need some way to group tabs. Users like me found it frustrating to have to jump back and forth between a secondary, abstracted environment (Panorama) and the normal Firefox user environment anyway. We just wanted easy tab grouping. I have several "workspaces" running at once, and I need to quickly be able to jump between sets of tabs grouped logically. So how does TabGroups Manager help me do that? (1) The most important feature: The add-on creates one level of hierarchy (Tab Groups) which are represented as an extra bar in the tab area. (Please see the screenshots on the add-on page.) This allows the user to organize Tab Groups directly in the main browser window view, without having to flip to a secondary "Panorama" screen. The user can create hierarchy, name the groups, and manage tabs (drag-and-drop between tab groups) in a quick, convenient way that provides visual context at all times. (2) Secondary feature: The add-on allows the user to hibernate tab groups to improve performance. The problem is, Panorama has sullied the concept of Tab Groups for too many developers and muddied the etymological waters of tab grouping. Users who wanted Tab Groups indeed used Panorama (terrible implementation as it was) - often in combination with add-ons which extended its functionality to make it actually useful - because when Mozilla forced its will in implementing Panorama as the solution for tab grouping, there were no other options. So users made do with Panorama. Now that it's been axed, that's why many users who liked some sort of tab grouping feature are shouting for its return. Maybe they don't fully realize that it's not "Panorama" (poor implementation of Tab Groups, but the one that they recognize) that they want, but simply a useful implementation of Tab Groups. The concept behind TabGroups Manager is an incredible workflow booster. Please check it out and review it in light of your thoughts about the way forward. Of course, the add-on will no longer work in Firefox 57+. To me, it doesn't make sense to be forced to have tabs completely disorganized, which is the current new paradigm in Firefox.

I found a Firefox native workaround for Tab Groups and Tab Groups Menu functionality. I'm using bookmarks and bookmarks folders and subfolders for it. It's not perfect, but it can also serve as a basic model for a (perfect) webextension. You see, I believe that by using these native techniques, one can make a super simple and lightweight webextension! More detailed and illustrated info on it in this article: http://attic.e-motiv.net/fyi/tab-groups-workaround

> http://attic.e-motiv.net/fyi/tab-groups-workaround The 'Open All in Tabs' workaround is relatively heavyweight. The combination of traditional Tab Groups + browser.sessionstore.restore_on_demand is relatively lightweight.

(In reply to 0RUBn0 from comment #18) > I found a Firefox native workaround for Tab Groups and Tab Groups Menu > functionality. I'm using bookmarks and bookmarks folders and subfolders for > it. Sounds similar to this proposal: bug #1366478.

(In reply to Graham Perrin from comment #19) > > http://attic.e-motiv.net/fyi/tab-groups-workaround > > The 'Open All in Tabs' workaround is relatively heavyweight. > > The combination of traditional Tab Groups + > browser.sessionstore.restore_on_demand is relatively lightweight. I am wondering if there are not two ways of looking at lightweight? 1. Conserve memory (and CPU via background scripts) 2. Conserve CPU on the time of swapping tab group. If I think about Graham's lightweight, I'm guessing it's only number 2, because all the inactive tabs are still real tabs and might be targeted by a lot of event-listening and other background scripts (including from other add-ons). If I'm thinking bookmarks workaroudnd, I'm guessing 1, because there are no real (inactive) tabs anymore, (and 2*) ? * I'm also generally wondering how it's possible that "Tab Groups + browser.sessionstore.restore_on_demand is relatively lightweight", compared to a native Firefox function? Any insights or details on that to help me understand? Thanks. --------------------------------------------------------- (In reply to devurandom from comment #20) > > I found a Firefox native workaround > > Sounds similar to this proposal: bug #1366478. Indeed! Though it asks much more than that; why I'm wondering if it will ever be pushed (together with the huge waiting list of bugs and feature requests from webextensions onwards)..

(In reply to 0RUBn0 from comment #18) > I found a Firefox native workaround for Tab Groups and Tab Groups Menu > functionality. I'm using bookmarks and bookmarks folders and subfolders for > it. > It's not perfect, but it can also serve as a basic model for a (perfect) > webextension. You see, I believe that by using these native techniques, one > can make a super simple and lightweight webextension! > > More detailed and illustrated info on it in this article: > http://attic.e-motiv.net/fyi/tab-groups-workaround IMO, calling this a workaround is using the term in the loosest sense. It is like calling using an office building a workaround for a house to live in. Yes, technically one could live there, bring in a few cots to sleep on, cook your food in the break room microwave... Moreover, it actually isn't a workaround - saving bookmarks is not the same thing as persisting tabs, which preserves the browsing history for each tab.

(In reply to 0RUBn0 from comment #18) > I found a Firefox native workaround for Tab Groups and Tab Groups Menu > functionality. I'm using bookmarks and bookmarks folders and subfolders for > it. (...) > http://attic.e-motiv.net/fyi/tab-groups-workaround I already saw a Chrome extension that uses this kind of UI... Unfortunately I wasn't able to find it in the store (there a a LOT of tab management extensions on Chrome... yes, this is a need for lots of users !!) My very naive question : could a Chrome extension be ported to Firefox ? As multibrowser is one of the benefits of webextensions ?

I would like to request that someone provide a summary of status on this issue as of today. Thanks in advance!

Bug 1423725 landed two days ago, not sure how much in turn is left for bug 1384515. After that is considered done, I guess everything tab groups could once do would be there.

This is working fine for me in Firefox 59 beta : https://addons.mozilla.org/firefox/addon/basic-panorama/ (with extensions.webextensions.tabhide.enabled to true)

Bulk move of bugs per https://bugzilla.mozilla.org/show_bug.cgi?id=1483958

If people are hunting for panorama implementations, Panorama Tab Groups https://addons.mozilla.org/en-US/firefox/addon/panorama-tab-groups/ appears to be actually maintained although a lot is missing from the pre-web extensions version (search filtering for easy location of tabs when number grows to a few hundred and alternate layouts). Also it's still pretty buggy, for example using the backup mechanism is critical since every restart will lose your tabs - this is apparently an unfixed firefox limitation. And, compared to pre-webextension, the UI has a bit clunkier a feel to it, it's clearly a WIP - but the main issue I'd say is losing your tabs. I put up with it just 'cause I love the visual tab arrangement model of panorama/tabcandy.

Marking this as fixed since the tab hiding API provides support for tab groups. The other requests don't seem critical for a tab groups implementation (and we now have tab groups implementations). Those requests can be tracked in their own bugs.