590563 - Manually restored tabs are not shown in the main browser view

Status: VERIFIED FIXED

(Firefox Graveyard :: Panorama, defect, P2)

Description

[Antoine Turmel [:GeekShadow]]

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

My Firefox crashed, with about:sessionrestore I did reopen some tabs by using middle click of mouse, problem is they doesn't show on main view. After a quick look on Panorama, all restored tabs are throw without being grouped on one view. After restoring all of these, it forms the view without Panorama's group window.

Reproducible: Didn't try

Steps to Reproduce:
1. Crash Firefox with multiples tabs in multiple Panorama views.
2. Use about:sessionrestore and try to restore tabs by using middle-click of mouse to restore them in new tabs.
3. Use Panorama button.
Actual Results:  
My tabs are not open in main view, and there are in Panorama, without a parent group.

Expected Results:  
My tabs are opened in main view, or Firefox open them in matching group and switch to this group. (recreating the group)

Comment 1

[Antoine Turmel [:GeekShadow]]

Attachment: bug in panorama view (tabs openend without a parent group)

you can see some of my games tab at the right of screenshot, they are restored from about:sessionrestore but don't seems to have a parent group, tought they seems aligned...

Comment 2

[Aza Raskin [:aza]]

Can someone confirm this bug?

Comment 3

[Aza Raskin [:aza]]

I believe this is now fixed in the latest nightly's. Antoine, can you please confirm?

Comment 4

[Antoine Turmel [:GeekShadow]]

Attachment: same bug, in 4.0b8pre (under linux)

Comment 5

[Antoine Turmel [:GeekShadow]]

(In reply to comment #3)
> I believe this is now fixed in the latest nightly's. Antoine, can you please
> confirm?

Still an issue for me, tested in 4.0b8pre latest nightly on Linux (Ubuntu 10.10)

This time, I was unable to restore using middle-click of mouse, so I did restore with the "Restore" button.

To get the about:sessionrestore, I did kill two time the firefox process.

Comment 6

[Ian Gilman [:iangilman]]

Sounds like it still exists then... reopening.

Comment 7

[Antoine Turmel [:GeekShadow]]

It could be linked to Bug 598600

Comment 8

[Kevin Hanes]

Promoting in priority and schedule, as it is blocking.

Comment 9

[Dietrich Ayala (:dietrich)]

Not going to hold the release for this. Panorama depends on your session, which hasn't yet been restored. It's an awkward situation, but it's narrow and there's no real dataloss.

Comment 10

[Kevin Hanes]

bugspam (moving b9 to b10)

Comment 11

[Kevin Hanes]

bugspam (removing b9)

Comment 12

[Michael Yoshitaka Erlewine [:mitcho]]

Hopefully we can investigate this in beta 11.

Comment 13

[Julien Wajsberg [:julienw]]

I'm not sure that belongs to the same bug, but I get something close to this, but I get it differently.

Quite often, I reopen tabs that I accidentally closed using ctrl + shift + t (the same happens using the menu History > recently closed tabs).

Since version 4b9 (I think), when I do that, it reopens in another panorama session, switching to this new session. And so I lose the session I was in.

The result I'd want is : the tab should be reopened in the same panorama session as it was, ie the one I am currently in.

That is _really_ painful.

Comment 14

[Julien Wajsberg [:julienw]]

Maybe I should open a new bug since I get the reopened tabs in a new panorama group, they're not "standalone" like the reporter said.

Comment 15

[Julien Wajsberg [:julienw]]

ok, thats Bug 624265, sorry.

Comment 16

[Raymond Lee [:raymondlee]]

The STR is a bit different now compared to the #comment 0

Steps to Reproduce:
1. Create two groups, each group with at least one tab item.
2. Go to main browser view.
3. Crash Firefox (Force quit on Mac)
4. On about:sessionrestore page, try restore tabs by using middle-click or cmd/ctrl left-click to restore them in new tabs.
5. The unhidden tab(s) would be created and displayed in the tabbar and the hidden one would be created as new hidden tabs and not visible in the tabbar.
6. Go to Panorama view and you will see all newly created hidden/unhidden tabs are in the same group.

Expected Results:
Since the hidden tabs are restored in new tabs, I think we should make them visible.

Comment 17

[Raymond Lee [:raymondlee]]

Attachment: v1

I couldn't find a way to set the window state without restoring tabs so I didn't write a automated test for this.  May be a litmus test would be better?

Comment 18

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

Comment on attachment 510957 [details] [diff] [review]
v1

(In reply to comment #17)
> I couldn't find a way to set the window state without restoring tabs so I
> didn't write a automated test for this.  May be a litmus test would be better?

So you could setBrowserState to load about:sessionrestore with a specific session - that's how we load the session restore page at startup and a couple other tests. See http://mxr.mozilla.org/mozilla-central/source/browser/components/sessionstore/test/browser/browser_581593.js for an example.

You should then be able to middle or double click on the list to open the tab & then make sure it's not hidden (I would wait for SSTabRestored before checking).

This is low risk without a test, but session restore is too regression prone (especially with all of this hidden stuff) to skip the test if it's possible to write one. So the change looks fine, but r- until there's a test.

Comment 19

[Raymond Lee [:raymondlee]]

Attachment: v2

Added test.

Passed Try. http://tbpl.mozilla.org/?tree=MozillaTry&rev=7ed64ef772af

Comment 20

[Dietrich Ayala (:dietrich)]

Comment on attachment 511395 [details] [diff] [review]
v2

low footprint, has test, passed try -> a+

Comment 21

[Michael Yoshitaka Erlewine [:mitcho]]

Attachment: Patch for checkin

Comment 22

[(no longer active)]

http://hg.mozilla.org/mozilla-central/rev/79266a9bfbeb

Comment 23

[George Carstoiu]

Mozilla/5.0 (Windows NT 6.1; rv:2.0b12pre) Gecko/20110215 Firefox/4.0b12pre

Verified issue and it's no longer reproducible.