Closed Bug 590563 Opened 12 years ago Closed 12 years ago

Manually restored tabs are not shown in the main browser view

Categories

(Firefox Graveyard :: Panorama, defect, P2)

x86
Windows 7
defect

Tracking

(blocking2.0 -)

VERIFIED FIXED
Firefox 4.0b12
Tracking Status
blocking2.0 --- -

People

(Reporter: GeekShadow, Assigned: raymondlee)

References

Details

Attachments

(3 files, 2 obsolete files)

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)
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...
Priority: -- → P4
Can someone confirm this bug?
Assignee: nobody → jbecerra
I believe this is now fixed in the latest nightly's. Antoine, can you please confirm?
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
(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.
Sounds like it still exists then... reopening.
Assignee: jbecerra → nobody
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: WORKSFORME → ---
blocking2.0: --- → ?
It could be linked to Bug 598600
blocking2.0: ? → betaN+
Promoting in priority and schedule, as it is blocking.
Blocks: 598154
Priority: P4 → P2
Assignee: nobody → ian
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.
blocking2.0: betaN+ → -
bugspam (moving b9 to b10)
Blocks: 608028
bugspam (removing b9)
No longer blocks: 598154
Hopefully we can investigate this in beta 11.
Assignee: ian → nobody
Blocks: 627096
No longer blocks: 608028
Keywords: qawanted
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.
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.
ok, thats Bug 624265, sorry.
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.
Assignee: nobody → raymond
Status: REOPENED → ASSIGNED
Summary: Manually restored tabs are not located in a panorama view nor the main view → Manually restored tabs are not shown in the main browser view
Attached patch v1 (obsolete) — Splinter Review
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?
Attachment #510957 - Flags: review?(paul)
Attachment #510957 - Flags: feedback?(ian)
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.
Attachment #510957 - Flags: review?(paul) → review-
Attached patch v2 (obsolete) — Splinter Review
Added test.

Passed Try. http://tbpl.mozilla.org/?tree=MozillaTry&rev=7ed64ef772af
Attachment #510957 - Attachment is obsolete: true
Attachment #511395 - Flags: review?(paul)
Attachment #510957 - Flags: feedback?(ian)
Attachment #511395 - Flags: review?(paul) → review+
Attachment #511395 - Flags: approval2.0?
Comment on attachment 511395 [details] [diff] [review]
v2

low footprint, has test, passed try -> a+
Attachment #511395 - Flags: approval2.0? → approval2.0+
Attachment #511395 - Attachment is obsolete: true
http://hg.mozilla.org/mozilla-central/rev/79266a9bfbeb
Status: ASSIGNED → RESOLVED
Closed: 12 years ago12 years ago
Flags: in-testsuite+
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 4.0b12
Mozilla/5.0 (Windows NT 6.1; rv:2.0b12pre) Gecko/20110215 Firefox/4.0b12pre

Verified issue and it's no longer reproducible.
Status: RESOLVED → VERIFIED
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.