This is easily reproducible for me... 1) I have ~12 tabs, 3 in one (active) group and the rest in another group. One of the tabs in the inactive group is https://intranet.mozilla.org/, which requires HTTP auth. 2) Restart browser 3) When the browser window comes up, I correctly see just the 3 tabs that are supposed to be shown (ie, from the active group) 4) A couple seconds later, as session restore gets around to loading tabs from the active group, I get an HTTP Auth prompt shown, and when that happens all the tabs from the inactive groups suddenly appear in the tab strip. 5) When I enter Panorama again, all (or almost all) tabs have been moved to a single group. Sometimes a couple tabs get left in the other group, it seems rather random. Expected results: Not sure what's intended to happen when a background group triggers an auth dialog (switch to it or not?), but it certainly shouldn't combine all my tabs into 1 group.
Created attachment 507004 [details] Video I couldn't reproduce this bug. The tab with page which requires HTTP auth doesn't load until you select that tab after Fx restart (See attached video). May be I am missing something?
Also note that I wasn't able to reproduce bug 614727, which is similar.
FWIW, this is happening for me (4.0b11pre 2011-01-30 on Mac OS X) 1) Have this open in a tab: https://intranet.mozilla.org/User:Lorchard@mozilla.com/Goals/2011/Q1 2) Quit and restart browser. 3) HTTP Basic auth dialog appears for intranet page, which seems to interrupt the process of restoring tabs to groups Tabs loaded before the auth dialog seem to be restored fine, all tabs restored after the one requiring auth appear in the same (incorrect) group.
I cannot reproduce this. When opening the browser the auth dialog pops up and shows the tab group the basic auth tab belongs to. This is not really what the users wants but at least there are no misplaced tabs for me.
(In reply to comment #5) > I cannot reproduce this. When opening the browser the auth dialog pops up and > shows the tab group the basic auth tab belongs to. This is not really what the > users wants but at least there are no misplaced tabs for me. Well, not sure how to better explain how to reproduce :/ Suggestions welcome. It definitely happens for me with every restart (eg. with a nightly upgrade), and it annoyingly wrecks all my tab groups so that I have to manually reorganize them every time
(In reply to comment #6) > It definitely happens for me with every restart (eg. with a nightly upgrade), > and it annoyingly wrecks all my tab groups so that I have to manually > reorganize them every time Ok, just to make sure: are you using any specific add-ons? Are you using the "Hard Blockers Counter" add-on (bug 628188)?
(In reply to comment #7) > Ok, just to make sure: are you using any specific add-ons? Are you using the > "Hard Blockers Counter" add-on (bug 628188)? Yeah, add-ons occurred to me the exact second I posted that last semi-frustrated comment. Doh. It looks like maybe a Jetpack add-on is a culprit, and bug 628188 is indeed my issue. I disabled all addons, restarted, manually reorganized my tabs. I quit & started again, all tab groups were fine. Then, I re-enabled add-ons one at a time, restarted after each, all tab groups fine. It wasn't until I re-enabled the one Jetpack / Add-on SDK based add-on (Fireriver) that the problem happened. That also happens to be an add-on I wrote, so I can tweak it if necessary. https://addons.mozilla.org/en-US/firefox/addon/fireriver/
(Oh, and yes, Fireriver uses the "tabs" module as discussed in bug 628188)
(In reply to comment #9) > (Oh, and yes, Fireriver uses the "tabs" module as discussed in bug 628188) Ok, thanks for your help! So let's dupe this against bug 628188 and concentrate on that one :)
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 628188
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.