Closed Bug 445461 Opened 16 years ago Closed 10 years ago

MRU tab order lost when restoring a session

Categories

(Firefox :: Keyboard Navigation, defect)

defect
Not set
normal

Tracking

()

VERIFIED FIXED
Firefox 30

People

(Reporter: dao, Assigned: dao)

References

(Blocks 1 open bug)

Details

(Keywords: ue)

Attachments

(1 file, 1 obsolete file)

The most-recently-used tab order from bug 395980 is currently lost when a session is restored. We should probably store that information.
Blocks: 345684
please make sure that there is an option to use most-recently-used tab or the default (system wide) logical ordering.  if you have ten to twenty tabs up, i challenge that absolutely no one can remember without a lot of difficulty how many times they would have to hit ctrl tab to get to the window.  mru is not logical behavior anyway.
if a tab is three to the left, you ought to be able to hit ctrl-shift-tab,tab,tab to reach it.  at current, you have no way of knowing how many times you have to hit it, and waste your time looking at the preview panel
Veritas:  once again, read the dependencies to bug 395980 and stop spamming random CTRL+TAB related bugs!  Here is the link, https://bugzilla.mozilla.org/showdependencytree.cgi?id=395980&hide_resolved=1 most importantly; bug 445499:  "Allow Ctrl+Tab preview to display in tab bar order"
Depends on: 586067
Attached patch patch (obsolete) — Splinter Review
Assignee: nobody → dao
Status: NEW → ASSIGNED
Attachment #8371885 - Flags: review?(ttaubert)
Comment on attachment 8371885 [details] [diff] [review]
patch

Review of attachment 8371885 [details] [diff] [review]:
-----------------------------------------------------------------

When restoring windows other than the first one (e.g. restoring multiple windows, undo closing a window) we're listening for the load event and will call ss.restoreWindow() on the next tick, which might be before delayedStartup() is called. ctrlTab would thus initialize after SSWindowStateReady has fired. I think ctrlTab should do the same on .init() as on SSWindowStateReady and initialize with a sorted list of visible tabs.
Attachment #8371885 - Flags: review?(ttaubert) → feedback+
It also occurs to me that hidden tabs need to be included, otherwise the MRU data will be missing when switching tab groups.
Attached patch patch v2Splinter Review
Attachment #8371885 - Attachment is obsolete: true
Attachment #8372164 - Flags: review?(ttaubert)
Comment on attachment 8372164 [details] [diff] [review]
patch v2

Review of attachment 8372164 [details] [diff] [review]:
-----------------------------------------------------------------

Good catch wrt to hidden tabs.
Attachment #8372164 - Flags: review?(ttaubert) → review+
https://hg.mozilla.org/mozilla-central/rev/f34185ced01a
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 30
Keywords: verifyme
Currently, the lastAccessed stamp is not set on a never accessed new background tab, which will have lastAccessed = 0 stored. This does not match how ctrlTab handles a new tab. 
I'll open a new bug for this.
Depends on: 980231
Verified as fixed using the following environment:

FF 30.0b5
Build Id:20140515140857
OS: Windows 7 x64, Mac Os X 10.8.5, Ubuntu 13.04 x64
Status: RESOLVED → VERIFIED
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.