Closed Bug 624727 Opened 14 years ago Closed 13 years ago

Removed app tabs get overriden and reused in nsSessionStore::restoreWindow()

Categories

(Firefox :: Session Restore, defect, P2)

defect

Tracking

()

VERIFIED FIXED
Firefox 4.0b11
Tracking Status
blocking2.0 --- final+

People

(Reporter: vladmaniac, Assigned: ttaubert)

References

Details

(Whiteboard: [softblocker])

Attachments

(6 files, 1 obsolete file)

Attached image screenshot
Build ID:

Mozilla/5.0 (Windows NT 6.1; rv:2.0b9) Gecko/20100101 Firefox/4.0b9

Steps: 

1. Navigate some tabs
2. Enter panorama and put the tabs into two or more groups. (min is 2) 
3. Make some app tabs. (two will do) 
4. Go private browsing 
5. Enter panorama again 

Behavior: 

Groups from normal mode are saved in PB due to app tab presence 
Exiting private browsing mode will also result in destroying group organizing 

Note: see screenshot
Whiteboard: [4b9]
Blocks: 585689
Priority: -- → P2
Mozilla/5.0 (Windows NT 6.1; rv:2.0b9) Gecko/20100101 Firefox/4.0b9

Able to reproduce. After entering private browsing mode able to see the tabs groups and app tabs in panorama view. After exiting PB mode, tabs groups are destroyed.
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b10pre) Gecko/20110119 Firefox/4.0b10pre

Unable to reproduce on trunk. Please see attached video for to see the steps I followed.

If this still occurs, STR which consistently produce the problem would be helpful, and we should nominate this to be a blocker. Otherwise, though, we should close it.
Blocks: 627096
No longer blocks: 585689
Keywords: qawanted
Whiteboard: [4b9] → [4b9][WFM?]
Attached video Doesn't work for me
I can reproduce this. See the video.
Using FF 4.0b10 on WinXP x64:

1. Navigate some tabs (3 mini)
2. Out of those tabs create min 2 AppTabs
3. Create one of more groups out of the remaining tabs
4. Go private browsing
5. Stop private browsing
6. Enter panorama

Expected behaviour: tab groups, tabs and app tabs are recreated as when entering Private Browsing.

Actual behavious: tab groups are recreated empty, regular tabs are all stacked up in the upper left corner, app tabs are ok. No easy way to recreate the proper settings unless stopping FF with save tabs option checked and restarting.
Mozilla/5.0 (Windows NT 6.1; rv:2.0b10pre) Gecko/20110125 Firefox/4.0b10pre

Also, after issue is reproduced, new created tabs are displayed in tab view as being part of the group, but in Panorama they are displayed in the top left corner as part of a separate group. (See screenshot 1 and 2 that display the behavior of the same opened pages in both Panorama and Tab view)
Attached image Screenshot 1
Attached image Screenshot 2
Assignee: nobody → tim.taubert
Status: NEW → ASSIGNED
OS: Windows 7 → All
Hardware: x86 → All
Reliable STR:

1.) Have two tabs.
2.) Pin them both.
3.) Enter private browsing mode.

Result:

Error: maxVisibleTabs.stop is not a function
Source File: file:///home/tim/workspace/mozilla-central/objdir-ff-release/dist/bin/components/nsSessionStore.js
Line: 2522

After that the browser works as expected but panorama is broken and produces the weird states described in former comments. So this is a rather PB/SS related bug.
blocking2.0: --- → ?
Keywords: qawanted
Whiteboard: [4b9][WFM?]
Blocks: 625988
Explanation:

When having two app tabs and switching to PB, restoreWindow() is called with
openTabs=2 and newTabs=1. So the first of the two app tabs will be overridden.
In the for loop the first tab gets unpinned and so immediately moved behind the
second app tab. The second loop iteration accesses this first tab again
(because gBrowser.tabs[] is accessed directly) and removes it. So the session
store is going to use a removed tab.
Component: TabCandy → Session Restore
QA Contact: tabcandy → session.restore
Summary: Presence of app tabs while in Private browsing mode break tab organizing in group view → Removed app tabs get overriden and reused in nsSessionStore::restoreWindow()
Blocks: 626527
Attached patch patch v1 (obsolete) — Splinter Review
Pushed to try.
Attachment #507807 - Flags: review?(ian)
Attachment #507807 - Flags: review?(paul)
blocking2.0: ? → final+
Whiteboard: [softblocker]
Comment on attachment 507807 [details] [diff] [review]
patch v1

Thanks again for looking into this.

>+++ b/browser/components/sessionstore/src/nsSessionStore.js
>+    // unpin all tabs to ensure they are not reordered in the next loop
>+    if (aOverwriteTabs) {
>+      for (let t = tabbrowser._numPinnedTabs-1; t > -1; t--)

Nit: tabbrowser._numPinnedTabs - 1

>+++ b/browser/components/sessionstore/test/browser/browser_624727.js
>+  is(gBrowser.tabs[0].linkedBrowser, linkedBrowser, 'first tab\'s browser got re-used');

Nit: I wouldn't say anything if you didn't have to escape a quote, but please just use double quotes throughout.

Test looks good. Assuming it's failing without your patch (it should be), r=zpao.
Attachment #507807 - Flags: review?(paul) → review+
Alright I'll fix that :) I ensured that both tests are failing without the patch applied.
Comment on attachment 507807 [details] [diff] [review]
patch v1

I just reviewed the Panorama test; looks beautiful!
Attachment #507807 - Flags: review?(ian) → review+
Attachment #507807 - Attachment is obsolete: true
Passed try!
Keywords: checkin-needed
Pushed http://hg.mozilla.org/mozilla-central/rev/a76570899a34
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Flags: in-testsuite+
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 4.0b11
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: