As one of those pathological users that often keeps 50+ tabs open (somewhat manageable with the tabgroups addon), I'd hate to see one of the principal Firefox advantages go away.
[1] https://addons.mozilla.org/en-US/firefox/addon/tree-style-ta...
[1]: https://addons.mozilla.org/firefox/addon/session-manager/
https://addons.mozilla.org/en-US/firefox/addon/tab-groups-pa...
Without you as a user having to do anything other than simply open up new tabs as is natural in your workflow, you create an explicit structure which shows the relation of various browser tabs to one another. The best thing about this is that you can treat an entire tab tree or subtree as a task, and when you are done, clear it out.
Other elements of TST are that it can be placed as a sidebar, which, in this world of Very Wide Screen Displays, takes up extraneous space (for textual presentation) on the side of your screen, and frees up the precious and limited vertical space for more text state.
I've tried several times, and largely given up, on explaining to Google's Peter Kasting (one of the core Chrome devs) why this is so useful. Google are apparently adopting the GNOME and systemd view that:
1. If you're a technically advanced user, you're not our target user base.
2. If you're not a technically advanced user, you're not qualified to comment on what's wrong with the product.
Somehow, that never quite seems to work out right.
Firefox's flexibility, particularly with tabs, is why I continue to use it despite some performance and functional advantages to Chrome.
(On Android, Chrome's lack of adblock makes it almost entirely useless. I've salvaged it slightly through putting a hosts + DNSMasq adblock on my router -- DD-WRT. But that's only just barely sufficient. Adverts are a complete pox on the Web now.)
There is something that I've wondered about for a while on this Electrolysis fanciness: currently Firefox is said to be single-process. So why do I see tens of "firefox" threads in htop?
So this means any performance increase will be coming from rewriting old code in a more efficient way, which could be done independently of e10s, right?
I mean, since the new multiple processes will not share address space, there will have to be explicit communication between processes with corresponding overhead and blocking? So a priori one would expect the new code to be slightly slower? And use more memory, since some data needs to be duplicated between processes?
What also comes to mind is that introducing e10s is like taking an OpenMP-parallel code and turning it into an MPI+OpenMP-parallel code.
If you are anything like me you have a number of windows open for some project or research thing and you had one extra tab that you left open as the last active tab in the window but it's unrelated to the other 10 tabs in that window. The windows menu doesn't help you because that is the tab that is listed as the title of that window.
It's free and opensource[1] for Chrome[2] and Firefox[3].
1. https://github.com/fiveNinePlusR/tabist
2. https://chrome.google.com/webstore/detail/tabist/hdjegjggiog...
3. https://addons.mozilla.org/en-US/firefox/addon/tabist/
If you try it and like it/hate it let me know what you might want put into future versions to keep it good/change your opinion of it to the better. It's still early in its development but what's implemented works well so far. Cheers!
Edit: There is a bug in Firefox that I have a patch submitted that will allow the tab titles to show up correctly even when they have been unloaded. for now it shows the URL of the tab until it has been loaded. The patch should land by Firefox 51 hopefully.
I've raised a few issues on github, feel free to ignore them!
Using the Awesomebar and typing "%" and a tab name will find the tab. Navigating to it and clicking (or pressing enter) will open the tab in its existing window.
Docs here: https://support.mozilla.org/en-US/kb/awesome-bar-search-fire...
If you liked the extension I'd love to know what you'd like to see. If you hated it I'd love to know why. Either way thanks for trying it out!
> For each change to Mozilla's inbound repository, our build infrastructure
> generates a build which we test and include in the graphs here.
IIRC, Firefox has(had?) a lot of old code written long before modern concerns were even fathomed; addons back-in-the-day had access to the entire process-- every tab, all the DOM, and everything shared the same namespace (shady calls from webpages were blocked somehow, not sure if it was true sandboxing or not), so AMO mods would block addons (or updates) that didn't adhere to their namespacing policy. I'd bet a lot of that integration is still there, and most of what we're seeing is the result of what is probably a very messy untangling.