I think this is pretty bad behaviour, could be looked at as dataloss even. Ultimately, it looks like bug 587874 is the real fix, but I don't think we should ship with the current behaviour.

I believe that this should block 4.0 final, not sure what else to say beyond what's in the summary/comment#0.

(In reply to comment #0) > I think this is pretty bad behaviour, could be looked at as dataloss even. > Ultimately, it looks like bug 587874 is the real fix, but I don't think we > should ship with the current behaviour. Actually, I disagree. If you have closed a tab and moved on to the next group (this would have to be explicit action, as closing a solo tab would get you back into the Panorama UI, only by ctrl+` or clicking another group would you move) it would make sense for the tab to appear in the group you are currently in. It would be far more confusing, for instance, if you were in one group and hit "undo close tab" and nothing happened (because the tab was added to its previous group). You would have to add a visual indicator to the the Firefox UI that an action had been performed. It is much more logical for it to appear in the group you have taken all the effort to put yourself in. I do think that if you are in the Panorama UI when you hit "undo close tab", you should remain in the Panorama UI, (instead of immediately being that tab, regardless of group) but that's a different thing.

(In reply to comment #2) > It would be far more confusing, for instance, if you were in one group and hit > "undo close tab" and nothing happened (because the tab was added to its > previous group). You would have to add a visual indicator to the the Firefox UI > that an action had been performed. It is much more logical for it to appear in > the group you have taken all the effort to put yourself in. Oh, I was working on assumption that "Undo Close Tab" in this scenario would take you to the group of that tab. I definitely don't think you should see no visual change when doing undo close tab. I still feel strongly that it shouldn't appear in the current group, though.

(In reply to comment #3) > I still feel strongly that it shouldn't appear in the current group, though. Hmm. I can see that, but I have a suspicion that it would be a much worse interaction to drag the user from the place they explicitly put themselves into whatever group the old tab was. Assigning to Aza for design.

I don't think this blocks. Either way you go, the tab does get restored, and the only dataloss would be the state of which group the tab was in. From an interaction standpoint, I think it's far less likely that the user would prefer to be switched back to the old group that the tab was closed in. The current behavior does exactly what the user is telling the browser to do - I'd presume (perhaps mistakenly) that the user wants that tab back in the context of whatever they currently happen to be doing.

Until we get per-group undo stacks (587874) the exact interaction is a stop-gap measure. I'm agree with Dietrich and Kevin that the least jarring of the interaction flow is to have the re-opened tab appear in your current group. Trying to undo a tab close and have your group jump will be a highly confusing side-effect.

Considering the specifications present at the link below, the closed tab should be restored in the group from which it was closed. https://wiki.mozilla.org/Firefox/Projects/TabCandy/Design/UndoCloseGroup Also see bug 587874 and Comment 6 from bug 586198. IMO the resolution of this bug should be changed from Wontfix to Reopened.