Tab Snooze – Snooze tabs for later
github.com
github.com
I found this feature by mistake, but I was thinking about something like this. I placed Tab Groups button next to Open New Tab button on the right, so it's accessible.
Keyboard shortcuts:
- Ctrl+Shift+E - show Tab Groups
- Ctrl+Backtick (Tilde) - switch Tab Group
Good thing with this setup is to use Suspend-Tab addon [2] so after few hours tab can unload itself. But it's seems broken now.
I would prefer extension which would suspend javascript execution on not active tabs with option to not suspend selected tabs or white list. But I couldn't find it.
Maybe I will have to write it myself, but I don't know is it possible. Note: 'suspend javascript execution' and not 'disable javascript and reload'.
[1] https://support.mozilla.org/en-US/kb/tab-groups-organize-tab...
[2] https://addons.mozilla.org/en-US/firefox/addon/suspend-tab/
You're looking for this [0]
Do you maybe know the reason it's no longer on Firefox Add-Ons? Firefox Add-Ons says it was removed by the author.
The basic idea that one can have first-class sets of tabs that are related is just great. You can name them, add or dismiss entire groups. Love it. Tabs are automatically persisted in their groups using the existing UI to add or dismiss tabs. IMO, this makes them far superior to manually managed bookmarks. When resuming a project, I just want to get back to my working state without having had to remember to save every important tab to some bookmark folder. In this regard, I look to tab groups as a memory prostheses, helping me to keep track of what I was/will be doing on a given project between times I'm working on it.
That said, I find that the desktop metaphor aka "messy desk full of papers" simply doesn't scale well for document storage and organization. It never has. It's nigh impossible to organize, refactor, etc. For example, moving tabs that have "leaked" from one project context (tab group) into another, or splitting out a group into a sub-project, is a major pain in the ass. At least Windows Explorer and OS X's Finder have some tools to enable easier drag-and-drop management. Tab Groups introduces the metaphorical constraints, but none of the other affordances of the aforementioned file managers towards allowing organization.
What I really want are organizational tools that let me efficiently manage and swap between various project contexts. Tab Groups have a big advantage over bookmarks here, since tab groups transparently maintain state -- you don't need to remember to save every tab you open to some bookmark folder. You just get your working state back later.
Also, Tab Groups made an incredibly unfortunate design decision: the set of groups is bound to a specific window. There's no way to open Window 1 on Tab Group A and Window 2 on Tab Group B. If you have two windows in flight, each with tab groups, you basically have to keep those two windows open forever (or as long as a window has any active groups). Again, the bookmarks model of a window-independent persistent store is far superior.
Last but not least, the current implementation is hampered severely by slow UI. Firefox opening one window with a bunch of tabs is very slow now, even though tab opening is deferred. I feel like this has been regressing, but haven't rigorously measured.
The proper Tab Group UI is also incredibly slow. It's interesting (by which I mean depressing) to compare the speed and fluidity of Tab Groups to Safari 8's iOS-like tab overview UI. Safari's UI is shockingly fast to appear, and it navigates quicker than a dolphin's dream. Tab Groups is just uniformly sluggish, even when it's not difficult to interact with. It's practically a cliché that web response speed matters enormously, but the Tab Groups UI is so slow that if it were a web page I'd often just give up on it and move on. As it is, I keep reducing my use of it because it's mostly too painful. This comes back to a big failure of tab groups as a memory prostheses -- it's got to be fast and fluid enough that it doesn't become an interference with working flow.
That last element also implies larger feature and performance work I'd like to see. For example, git-quick switching between tab groups. I should be able to type a shortcut, a few letters of a search for a tab group (or a tab search, e.g. all tabs tagged with "rust"), hit enter and immediately see those tabs. By "immediately", I mean "so fast that we need to add subtle animation to the UI to prevent change blindness".
This feature is not properly advertised, so I think that they did not put too much thought into it.
I would prefer simple list of lists. But what really would be good is tab tagging somewhat in style of dwm [1]. Shared between all windows.
* The backend is the existing bookmarks storage. This already supports both hierarchical organization and tagging.
* The API for accessing the backend is effectively a search that defines a writable view into bookmark storage. E.g. "folder X", "tag Y", etc. "A small matter of UX" required to work out sensible behavior in the event non-writable searches are allowed (e.g. "all bookmarks that are hits for word 'cake'"). Likewise, some additional per-view metadata might be required to maintain the user's tab ordering for views without an ad-hoc order such as tag-driven searches. Perhaps these cases could be accommodated via the addition of "smart folders" to the bookmark store, which encapsulate these searches, provide a place to stick search-specific metadata, subfolders with ad-hoc contents (e.g. user-opened tabs in that context), and so on.
* The window's tab list management would transparently read/write tabs into the view associated with that window.
* Window tab display should be screamingly fast. Got 100 tabs in that search? That window had better appear instantly.
Honestly, that last shouldn't be very hard. (Warning: famous last words.) I haven't looked into the FF code for this (and I'm sadly unfamiliar with FF's codebase), but what are now standard list-view optimization techniques[1] from mobile platforms should make this a cakewalk. Anything needed for display should be stored in the bookmarks and/or cached, and there's minimal object allocation involved.
[1] E.g. there only exist a number of view objects (say, visible tabs) equal to what can be displayed on-screen plus one or two. These are recycled as needed during any view movement (scrolling) or data change operations.
Hark, I hear an excuse to learn Rust and go check out Servo...!
This unfortunately doesn't make them totally stop. It would be interesting to see what happens in this area (maybe inactive tab javascript permissions, similar to location and fullscreen?).
I now have 6000 saved tabs that deep down I know I'll never look at. :-)
> (On the other hand, because this addon calls very unstable/internal APIs of Firefox itself, this can be disabled by Firefox's update in the future.)
I find "read it later" solutions less appealing because they're a big bucket where I put my anything that's mildly interesting. It's also an entirely separate section of the browser (or a whole other app) whereas this plugin leverages existing workflows.
I'm sure everyone is different but if I could snooze a bunch of tabs until the weekend or until I start my commute home, that'd be pretty cool.
Any and all questions welcome!
Good work!