Closed
Bug 445461
Opened 16 years ago
Closed 10 years ago
MRU tab order lost when restoring a session
Categories
(Firefox :: Keyboard Navigation, defect)
Firefox
Keyboard Navigation
Tracking
()
VERIFIED
FIXED
Firefox 30
People
(Reporter: dao, Assigned: dao)
References
(Blocks 1 open bug)
Details
(Keywords: ue)
Attachments
(1 file, 1 obsolete file)
3.13 KB,
patch
|
ttaubert
:
review+
|
Details | Diff | Splinter Review |
The most-recently-used tab order from bug 395980 is currently lost when a session is restored. We should probably store that information.
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"
Assignee | ||
Updated•15 years ago
|
Blocks: ctrl-tab-panel
Assignee | ||
Comment 4•10 years ago
|
||
Comment 5•10 years ago
|
||
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+
Assignee | ||
Comment 6•10 years ago
|
||
It also occurs to me that hidden tabs need to be included, otherwise the MRU data will be missing when switching tab groups.
Assignee | ||
Comment 7•10 years ago
|
||
Attachment #8371885 -
Attachment is obsolete: true
Attachment #8372164 -
Flags: review?(ttaubert)
Comment 8•10 years ago
|
||
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+
Assignee | ||
Comment 9•10 years ago
|
||
https://hg.mozilla.org/integration/fx-team/rev/f34185ced01a
Comment 10•10 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/f34185ced01a
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 30
Comment 11•10 years ago
|
||
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.
Comment 12•10 years ago
|
||
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.
Description
•