bugzilla.mozilla.org has resumed normal operation. Attachments prior to 2014 will be unavailable for a few days. This is tracked in Bug 1475801.
Please report any other irregularities here.

Make Tab Candy and automatic session restore play nice

RESOLVED DUPLICATE of bug 598600

Status

Firefox Graveyard
Panorama
P3
normal
RESOLVED DUPLICATE of bug 598600
8 years ago
2 years ago

People

(Reporter: sciguyryan, Unassigned)

Tracking

Details

(Reporter)

Description

8 years ago
Currently when you close the browser and then reload it, the tabs load back file but if you open a new tab then you will find that tab isn't added to the bucket - so it seems that Firefox should remember which "bucket" you were looking at when it restores the session.

Currently any newly opened tab after a session restore will end up on its own and will need to be manually assigned to a tab group from the Tab Candy panel.
(Reporter)

Updated

8 years ago
blocking2.0: --- → ?
I notice more than once only 2 of my tabs stayed in my default tab group upon restarting the browser with session restore.

Comment 2

8 years ago
If could have TabCandy play nice with BarTab extension or allow BarTab extension or similar to cater for it so that restarts could be much faster.  At present 100 tabs takes 2-3 minutes to restart Tab Candy.

With Bartab used to take 10-20 seconds.
(In reply to comment #2)
> If could have TabCandy play nice with BarTab extension or allow BarTab
> extension or similar to cater for it so that restarts could be much faster.  At
> present 100 tabs takes 2-3 minutes to restart Tab Candy.
> 
> With Bartab used to take 10-20 seconds.

This is a separate problem. Can you file a different bug for this?
The steps in comment #0 work for me in the latest nightly build.
Status: NEW → RESOLVED
blocking2.0: ? → -
Last Resolved: 8 years ago
Resolution: --- → WORKSFORME
I don't believe this works, I restore tabs all the time, and they don't put them into a default group, unless you first create a group, which I don't always want to do, the current window should create a group for itself if one doesn't exist as the sessions restores and any new tabs should go in this new group.
(In reply to comment #5)
> I don't believe this works, I restore tabs all the time, and they don't put
> them into a default group, unless you first create a group, which I don't
> always want to do, the current window should create a group for itself if one
> doesn't exist as the sessions restores and any new tabs should go in this new
> group.

That's a separate problem than the one described in comment #0, and your comment #1, which are:

1. restore a session
2. open tabview
3. open a group
4. open a new tab
5. restart

expected: new tab is in the group it was originally opened in

i believe there's already a bug for "put tabs in a default group automagically".

Comment 7

8 years ago
With the latest nightly (20100827), sessionrestore integration is broken. Steps:

Start a session.
Most tabs aren't in a group somehow; there is a small stack piled up at the same position at the bottom right corner of the tab candy view. If you select the top of that stack, all the other tabs disappear and become very hard to select.
Pick them one by one and group them.
Wait a bit, kill the browser.
Restore the session.
Show tabcandy. 
The tabs are hidden in that small pile at the bottom right. The grouping was forgotten.
Exit tabcandy. Land on some random tab; the tab bar is now empty but for the current tab. Other tabs are near-impossible to select.

So neither problem is solved for me. Tabs become ungrouped after restore, and manually grouping them is forgotten after a sessionrestore.
Ok, thanks for the feedback, reopening.

OnyxG7, can you check the error console after restarting, to see if there's anything in there?
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Target Milestone: --- → Firefox 4.0b5
Priority: -- → P3
Target Milestone: Firefox 4.0b5 → Future

Comment 9

8 years ago
This seems to be the same bug as https://bugzilla.mozilla.org/show_bug.cgi?id=589665

(Which means it's working ok again in Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:2.0b7pre) Gecko/20100922 Firefox/4.0b7pre)

Comment 10

8 years ago
Regressed again in  Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:2.0b7pre) Gecko/20101006 Firefox/4.0b7pre

Additional tabs appearing from other groups in tab bar on startup. Clicking the panorama button clears it all up; tabs are in the groups they belong again.

Error console: (Selected entries, too many to post)

* Could not find jar manifest entry 'chrome.manifest'.
* Error: Warning: unrecognized command line flag -foreground

Source File: jar:file:///Applications/Minefield.app/Contents/MacOS/omni.jar!/components/nsBrowserContentHandler.js
Line: 768

* Error: redeclaration of var Cc
Source File: chrome://mozapps/content/extensions/extensions.js
Line: 38

The rest seem to be errors+warnings on extentions. Will do another run in safe mode.

Comment 11

8 years ago
Same behaviour in safe mode;

One error in Error console:
* Error: Warning: unrecognized command line flag -foreground

Source File: jar:file:///Applications/Minefield.app/Contents/MacOS/omni.jar!/components/nsBrowserContentHandler.js
Line: 768
This bug has been marked as "future" (post-ff4.0) but it still blocked our ff4.0 milestone bug; removing blocking.
No longer blocks: 585689
I'm not sure how close this is to bug 598600, but it looks to have fixed the new tab opening case with session restore.  Not to mention maybe automagically into the current bucket.
This bug as described in comment 0 is a dupe of bug 598600. There were a couple other bugs that seem to be described in other comments, but should be fine now. Ian - I'll let you confirm & handle actually duping since you're paying attention to all of these bugs.

(In reply to comment #10)
> Additional tabs appearing from other groups in tab bar on startup. Clicking the
> panorama button clears it all up; tabs are in the groups they belong again.

This is one of those "other bugs" I mentioned, very possibly bug 607016.

> Error console: (Selected entries, too many to post)
Your errors there are all unrelated.

(In reply to comment #11)
> One error in Error console:
> * Error: Warning: unrecognized command line flag -foreground

You can ignore that error. It's something that gets added to the command line when restarting (I think). It does no harm.
Yes, looks like we can close this now; thanks, Paul.

If there are any remaining issues, they should be filed as new bugs.
Status: REOPENED → RESOLVED
Last Resolved: 8 years ago8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 598600
(Assignee)

Updated

2 years ago
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.