Step to reproduce:
1. make more than 2 tab group (say, group A and B)
2. open any page (say page P) with http authentication in the group A
3. select tab group B
4. restart Firefox
5. tab group B will be shown but it also contains the page P and asking user/pass of the page (basic or digest authentication dialog)
Note: Once user will switch to Panorama view, the page P will be only shown in the group properly.
Any pages should be always shown only in it's group (unless we support the tab alias feature?) even if the page require http authentication.
To solve this problem, Firefox should do one of:
a. ask user/pass when the user switch to the tab group
b. ask user/pass when the user switch to the tab (I prefer this)
Created attachment 505885 [details]
Hi dynamis, can you tell us if you still see this problem now?
I just tried this on trunk, and it seems like the login doesn't block the loading of Panorama or other tabs or anything, but that tab with a login did turn into a new tab on restart.
CC: zpao as this feels sessionstore-y.
The http auth dialog is window modal so it does cause us to focus that tab. However it looks to me like it's at least switching groups (though I get a brief wrong tab in group as it's transitioning)
It's a problem we've had before in sessionstore (people don't want the tab to be focused) but it's not something we can fix. If/when http auth dialogs become tab modal, that will fix it.
I wouldn't say WFM, but nothing to do about it at the moment.
(In reply to comment #2)
> I wouldn't say WFM, but nothing to do about it at the moment.
Punting to post Fx4, then.
I'm thinking this is still a problem, and more than you realize.
I've got hundreds of tabs open and about five different tab groups. When an HTTP authentication dialog pops up during a session restore, it aborts Panorama's sorting of tabs into their respective tab groups. That means once I take care of the dialog, a good portion of my tabs are left in the wrong tab group.
This is especially problematic because there is no way to sort more than one tab at a time (using multi-select or something), so resorting is very tedious.
I don't know if this issue is worth its own bug, but I the two are definitely related.
Fixed by bug 595601.