The tab groups have been switched off in Mozilla by McFee security s/w. How do I swith them back on?
The Tab Groups icon has also disapeared from the Customize oOptions menu.
There’s this popular addon here by @quicksaver -
https://addons.mozilla.org/en-US/firefox/addon/tab-groups-panorama/?src=search
Or did you mean that the add-on itself was removed by McAfee?
The Tab group addon has disappeared from the Options menu. So I cannot get access to all the Tabs I previously had in their respective groupings.
I’m not sure what you mean by options menu. Do you have the add-on installed and enabled in your add-ons manager (Ctrl+Shift+A)? If not, have you tried reinstalling it from the link noitidart posted above.
@quicksaver I’m deeply grateful for your work on the Tab Groups extension.
Looking ahead to Firefox 57 and WebExtensions:
- http://fasezero.com/ is noted and understood; and
- Containers will not meet my requirements
– so I seek an alternative.
https://addons.mozilla.org/firefox/search/?tag=tab+groups finds six extensions. For one of those – TabGroups Manager revived:
Please:
- can you think of any other extension that might gain WebExtensions compatibility?
Extension conflicts
From Violentmonkey compatibility reports for Firefox 55.0 (including 55.0.1):
Multiprocess disabled, hundreds of tabs, Session Manager and Tab Groups. After the session is restored: if (for example) the groups management interface is used whilst Violentmonkey is enabled, then Firefox 55 will very quickly stop responding. It becomes necessary to kill the firefox process, which is extraordinarily rare on FreeBSD.
Related:
– I chose to disable Violentmonkey.
Any other conflicts? (Use Mozilla’s Add-on Compatibility Reporter, if you like.)
Performance with Firefox 55
For me the most remarkable difference between versions 54.0.1 and 55.0 of Firefox was, I think, the reduced performance when first loading the groups management interface for each window.
Brief test results with 55.0.1, for a session with five hundred and sixteen tabs across eleven windows, after loading then unloading the interface for eight of the windows, the remaining three:
- 110 seconds for a window with 70 tabs (~1.6 seconds/tab)
- 574 seconds for a window with 142 tabs (~4.0 seconds/tab)
- 670 seconds for a window with 124 tabs (~5.4 seconds/tab).
YMMV, I suspect that performance would be better with multiprocess (e10s) enabled.
Reloads and unloads are fine, less than one second per window.
For ease of measurement, in about:tabgroups I have Enter and exit groups view bound to function key F8.
True.
I temporarily disabled ten extensions that are not compatible with multiprocess Firefox, restarted Firefox and timed a window with 151 tabs across 19 groups:
- 39 seconds.
Then set true for browser.tabs.remote.force-disable, restarted Firefox and timed the same window:
- 290 seconds.
~1.9 seconds per tab. That, on 2017-08-17, was probably with Firefox 55.0.2.
Now, with 55.0.3, two test results:
- ~0.3 second per tab (127 tabs across 24 groups: 41 seconds)
- ~0.2 second per tab (266 tabs across 25 groups: 60 seconds)
– much better.
89 extensions enabled, 42 of which are legacy, 15 of which are incompatible with multiprocess.
I wondered whether the previously poor results, with multiprocess not enabled, were symptomatic of issues with versions 55.0, 55.0.1 and 55.0.2 of Firefox.
I see nothing relevant in release notes for 55.0.3. Maybe the 2017-08-17 test result was from 55.0.1 and I was bitten by bug 1389381 - 16 Second Pause in ExtensionUtils.jsm’s truncate(), which was fixed in 55.0.2.
@dietrich hi, from Discontinuation of Tab Groups (Panorama) (2015-11-10) and from your https://github.com/autonome/Tab-Groups I see that you are, or were, a user of Tab Groups.
Your recent 1,691 tabs use case is widely appreciated for its focus on performance, but there’s no sign of grouping:
If not Tab Groups, then what now do you use?
Today: 906 tabs in seventy-six groups across thirteen windows.
Tab Groups with Firefox 56
First impression, after a few hours with 56.0 on FreeBSD-CURRENT:
- occasionally, a switch from one group to another is ineffective.
Workaround:
- switch away from the required group, then back to the group.
Gut feeling: it’s not an issue with Tab Groups. More likely an undefined side effect, or after-effect, of other issues that I observed today.
Postscript
I forgot, I added layout.css.servo.enabled as true in readiness, whilst still on 55. Today I changed it to false (the default); maybe the Tab Groups switching issue will not recur. A long shot.
To @dietrich:
Today I stumbled across this, from his write-up of an extension:
… when Firefox opens tabs at the end of 50 tabs, they’re almost guaranteed to be far from the tabs I was working with. I then find myself hunting around for the tabs I was just at, sometimes trying long and RSI-inducing drag-and-drop operations to regroup things.
Sure, if I wanted to strictly manage things, I could always have separate Panorama groups in this tab set, but often my workflow is more organic than that, and I end up in this place, and I should be able to continue working with the software in the way that my mind expects it to work.
So maybe this isn’t for you, …
– at https://addons.mozilla.org/addon/always-right/
(Always Right is a useful extension, but – for me – not a substitute for grouping.)
Hello! Right now I don’t use anything for tab grouping.
I’ve slowly been working on some of the APIs required for a tab groups replacement, but they’re still quite some ways away from being done.
1 Like
@dietrich cool, thanks. I see the works by you (and others) on bugs such as 1384515 - Provide an API for hiding and showing individual tabs.
Tab Groups with Firefox 56
These switching incidents seem to be rare.
I don’t yet have a screen recording of the issue in its purest form.
Here, instead, is a recording of something like a coincidence of (a) the restored session initially showing more than should be shown for a group; with (b) the more persistent switching issue:
Essentially:
- the containers group comprises nine tabs
- more than nine are shown.
A frame from the recording:
(That recording is far from an ideal example. The ‘switch away then back’ workaround was ineffective; there’s inconsistency between title, URL and content; and so on.)
Also there’s reopened Mozilla bug 1232178 - Support Tab Groups (aka Panorama) as a webextension and so on …
Related:
From the related Vimeo page:
… it seems that misbehaviour affecting Tab Groups sometimes occurs when switching:
- from a group where not all tabs are loaded
- to another group in the same window
– worked around by attention to the first of the two groups. Begin to load all of that group’s tabs …
– tested. No need to wait until those loads are complete.
A switch away, whilst loading all tabs, was an effective workaround.
I’ve used tab groups for a while and have looked at Tab Tree and Multiple Account containers as replacements but they seem ‘lacking’.
I don’t know much about coding add-ons, but it seems that bookmarking is akin to tab grouping anyway (as you group bookmarks) - so couldn’t FF have an extension to bookmarks where you can open the bookmark group rather than an individual bookmarked tab and that closes the currently open tabs and opens all the bookmarked tabs in that new group?