Closed Bug 604963 Opened 14 years ago Closed 9 years ago

Allow TabCandy to save some groups between sessions. (if you disable session saving, tab groups are lost, maybe unexpectedly)

Categories

(Firefox Graveyard :: Panorama, defect)

x86
All
defect
Not set
normal

Tracking

(blocking2.0 -)

RESOLVED WONTFIX
Future
Tracking Status
blocking2.0 --- -

People

(Reporter: ben.r.xiao, Unassigned)

References

Details

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Windows NT 6.1; rv:2.0b8pre) Gecko/20101016 Firefox/4.0b8pre
Build Identifier: Mozilla/5.0 (Windows NT 6.1; rv:2.0b8pre) Gecko/20101016 Firefox/4.0b8pre

Currently TabCandy is a bit useless for people who choose to load their home page or a blank tab on browser startup. All the groups that they created before are erased. There should be a preference that saves all TabCandy groups, including the one currently selected for display. When a new browser session is started, the user is greeted with their home page and when they click on the TabCandy button, all their groups from before are laid out.

Reproducible: Always

Actual Results:  
When the setting "When Minefield starts:" is not set to remember session, all TabCandy groups are deleted upon browser restart.

Expected Results:  
Create a new setting called "Remember TabCandy groups". When this is enabled, new sessions should display the homepage or a blank tab while having all TabCandy groups from previous session saved. This also means that the tabs displayed when Firefox was closed is also saved and placed as a group in the TabCandy screen.
Sounds awesome. Probably won't make the cut for ff4, but a useful feature.

Definitely blurs the area between bookmarks and tabs.
Target Milestone: --- → Future
I'm pretty sure this would be covered in Browser Restart work
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → DUPLICATE
(In reply to comment #2)
> I'm pretty sure this would be covered in Browser Restart work
> 
> *** This bug has been marked as a duplicate of bug 599213 ***

Bug 599213 is specific to Session Restore, whereas this bug does not appear to be. This feature sounds like we would want to implement it outside of Session Store and Session Restore (maybe the place history is stored). This would allow someone to load their previous tabs/groups, or possibly any time from their history.
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: DUPLICATE → ---
I think that tab groups should have a pin button. When this pin is activated, it is saved across sessions. When it is not it is deleted upon a new session.
blocking2.0: --- → ?
Version: unspecified → Trunk
Maybe this should really be an attribute of a group of bookmarks rather than of Panorama itself.  After all, what is a closed tab except a bookmark?  There is already a feature of bookmarks that allows a whole group of them to be opened in tabs.  Voila, instant tab group, just aching to be shown in Panorama.

On the other hand, what is a tab group when there are no tabs?  Nothing so far as I can tell.

So, what is Panorama, a means of grouping tabs, or a means of managing bookmarks?
Yes I thought of this, but Panorama groups not only save the URLs on the tabs, but also the current state of the tabs (scroll position, dynamic changes to the website via Javascript, etc.). Bookmark groups only save URLs not the state.

This is why I believe Panorama is a means of grouping tabs. Tabs represent current TASKS that users are doing, and therefore these tasks can be in varying states of completion. When you call a Panorama group to the front, the tab states are restored to how the user originally left them.

This is much different than restoring a bookmark group, where all the websites are refreshed to their original state.

Here's why I think pinning is useful. Imagine that I had a Panorama group with all of my incomplete tax forms partially filled out and then I decided to watch some Youtube before I go to sleep. I pin my tax group to Panorama and browse Youtube for a bit and then close Firefox and shutdown my computer. The next morning I wake up, launch Firefox in a new session displaying my homepage. I browse my homepage for a bit looking at today's news, etc. When I decide to stop procrastinating and finish my taxes, I can click the Panorama button, see that my tax group is still pinned there despite it being a new session, and open it up. Once it's open I see that all of my changes to the forms are still there and I can continue on.

So you see, if I had bookmarked my tax forms and tried to restore them later, I would lose all of my changes. I believe that the ability to pin groups is a huge usability benefit for Panorama and would help the feature become more widely used. No other browser has this feature.
I think I understand what you are looking for now.  I'm not an expert on Panorama or session restore but this seems like a major new step in functionality.  Session restore as I understand it operates to restore the entire session state (including page position, cookies, cache, etc.) immediately following a shutdown, and most importantly with nothing happening in between.

If you now want to save the session state for certain tabs for an arbitrary period of time, potentially with unknown operations occurring in the browser in between, then a whole can of worms opens.  Cookies could be overwritten, or not, new tabs could have been opened that would cause conflicts when trying to open (merge?) the saved session, cache states will change.  I'm sure there are dozens of nightmares I can't even imagine.  Already I've hit glitches when a component tried to do things too early during session recovery.
OMGYESPLZ. However, this is definitely significant new feature work, so not going to hold the release back for it, blocking-.
blocking2.0: ? → -
Could "open group" and "save group to file" be part of the scope? Saving the whole session sounds very ambitious, page position and tab history should be the first step. I think that the absence of a basic session manager in Firefox is really unfortunate now that Panorama is part of Firefox.
Attaching some mockups and copying a comment over from bug 622452:

-In future releases when we express multiple windows as tab groups (so a window
is just a view onto a particular tab group), users may start to create a large
number of groups without even knowing about panorama.  Some users still avoid
tabs, so 10 windows with 1 tab each would become 10 groups.  We don't want to
automatically restore the entire session on launch for these users, because
they may amass thousands of tabs/windows/groups over the life cycle of the
product.

-To keep these users from turning the tabstrip and panorama into a full history
UI (with every tab they've ever seen), we can automatically close all of their
tabs on exit, and allow them to restore their previous session when they
re-open the browser.

-However, if users have specifically created groups that they want to have
save, it is tedious for them to have to regularly click a button on launch to
restore their data (imagine having to hit button on launch to restore your
bookmarks).  They can opt to always restore their session (many people at
mozilla have this pref already flipped), but then it is tedious in that they
have to close a lot of unneeded tabs individually from time to time.  They
can't use the single action of a browser close to clean up their work space.

-One solution to this problem is to eventually create two levels of groups,
basically bookmarks versus session.  The distinction we've made previously in
the Firefox UI is:

Bookmarks: explicit user action.  The user creates data, like clicking a star
icon to say "never forget this"

Session/history: implicit user action. Firefox creates data, like opening a new
tab from a link the user clicked.

In this modal named groups (bookmarked groups) will always persist, and Firefox
will never forget them.  Unnamed groups will be tied to session restore.

If we list unnamed groups in the "Move to Group" sub-menu, once the user
interacts with that, they've done an explicit action equivalent to clicking a
star icon (they've created user data). So we would need to take that out of
session restore.  We could do that, but users probably wouldn't be able to
figure out why some groups persist, and others do not.  If we only list named
groups in the move to list, then users will become more familiar with the
process of creating a named group.  As part of this process we indicate to them
that the group will become persistent, through use of a star icon, more opaque
back, etc.  Note that if in this model the user clicks the star, and doesn't
type a name in, then we would need to provide a string like "Unnamed group 1"
(but it is still a starred/persistent/named group).
Summary: Allow TabCandy to save groups between sessions. → Allow TabCandy to save some groups between sessions.
Attached image Two levels of session restore (deleted) —
This introduces two levels of session restore.  A star icon is used for internal consistency with bookmarking (indicating that Firefox should never forget a piece of information).
Blocks: 578512
Depends on: 589665
The idea that immediately pops into my head is that this is great of people who don't flip the bit to save their session. Would these distinctions still be in the browser for users that elect to save their session? If not, aren't you worried about user confusion if Firefox behaves radically differently and even looks differently in parts? If so, what would their purpose be, as the session will already be saved/restored?

I think it's a fascinating idea, but it's going after a really narrow uses base: people who don't want to save session but would like to use Panorama between sessions.
I think the star button should be disabled for those who elect to have their session saved everytime they quit.

It's not a narrow use case because there are a lot of people who don't use session restore normally. For these users, Panorama is largely useless, as their session will most likely never use that many tabs to warrant it.
I think that session restore feels kind of dangerous for some people.  I know people have experienced data loss (losing the set of open tabs and tab groups from last time) because they either haven't shutdown Firefox properly (maybe they closed their main window with all their tabs before closing a secondary window which wasn't important) or some other quirk that resulted in their session not being available to restore next time around.

So I feel like there either needs to be a persistent history of sessions (so that you could go into the history window and say "open my windows/groups/tabs exactly as I had them yesterday at 5pm") or at least the ability to explicitly bookmark tab groups and the tabs that are within them.
howdy y'all,

bookmarking a tab group seems to end up here. if i am wrong, please point me to the correct bug.

what i want is to be able to bookmark a tab group _as_ a tab group. then i can reload/restore it from my bookmarks _as_ a tab group. right now i am using "bookmark all tabs" as a workaround. however, the behavior is not tab-group-like in that one must rebuild the tab group manually. 

if i'm in panorama then i want the tab group to reload there. if i'm NOT in panorama i want the tab group to either ...
- replace the current tab if it is blank
- send the current non-blank, non-grouped tab[s] into panorama as a new tab group & then load the saved tab group
- swap the current grouped tabs to panorama & then load the saved tab group

as an aside, i think the ability to "make the current tabs into a tab group" from the main window is a significant missing feature of panorama. sending them one-at-a-time to a group is tiresome and error prone. if a bug for that exists, would some kind person please point me to it?

take care,
lee
OS: Windows 7 → All
Summary: Allow TabCandy to save some groups between sessions. → Allow TabCandy to save some groups between sessions. (if you disable session saving, tab groups are lost, maybe unexpectedly)
Status: REOPENED → RESOLVED
Closed: 14 years ago9 years ago
Resolution: --- → WONTFIX
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: