Manually restored tabs are not shown in the main browser view

VERIFIED FIXED in Firefox 4.0b12

Status

defect
P2
normal
VERIFIED FIXED
9 years ago
3 years ago

People

(Reporter: GeekShadow, Assigned: raymondlee)

Tracking

unspecified
Firefox 4.0b12
x86
Windows 7
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(blocking2.0 -)

Details

Attachments

(3 attachments, 2 obsolete attachments)

(Reporter)

Description

9 years ago
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)
(Reporter)

Comment 1

9 years ago
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

Comment 2

9 years ago
Can someone confirm this bug?
Assignee: nobody → jbecerra

Comment 3

9 years ago
I believe this is now fixed in the latest nightly's. Antoine, can you please confirm?
Status: UNCONFIRMED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 5

9 years ago
(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: --- → ?
(Reporter)

Comment 7

9 years ago
It could be linked to Bug 598600
blocking2.0: ? → betaN+

Comment 8

9 years ago
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+ → -

Comment 10

8 years ago
bugspam (moving b9 to b10)
Blocks: 608028

Comment 11

8 years ago
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.
(Assignee)

Comment 16

8 years ago
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)

Updated

8 years ago
Assignee: nobody → raymond
Status: REOPENED → ASSIGNED
(Assignee)

Updated

8 years ago
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
(Assignee)

Comment 17

8 years ago
Posted 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-
(Assignee)

Comment 19

8 years ago
Posted 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)
(Assignee)

Updated

8 years ago
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

Comment 22

8 years ago
http://hg.mozilla.org/mozilla-central/rev/79266a9bfbeb
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago8 years ago
Flags: in-testsuite+
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 4.0b12

Comment 23

8 years ago
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.