Add tabs opened in the background to the top of the Ctrl+Tab list

VERIFIED FIXED in Firefox 3.1b1

Status

()

Firefox
Tabbed Browser
--
enhancement
VERIFIED FIXED
9 years ago
9 years ago

People

(Reporter: dao, Assigned: dao)

Tracking

Trunk
Firefox 3.1b1
Points:
---
Dependency tree / graph
Bug Flags:
in-litmus +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Assignee)

Description

9 years ago
Created attachment 330287 [details] [diff] [review]
patch

Beltzner writes: "When adding tabs without giving them focus, where should they be inserted into the MRU list? My feeling is that they should probably be added as if they were given focus, but it probably warrants experimentation."

Patch applies on top of the patches in bug 445369 and bug 445573.
Attachment #330287 - Flags: ui-review?(beltzner)
(Assignee)

Updated

9 years ago
Blocks: 395980
(Assignee)

Comment 1

9 years ago
Created attachment 333928 [details] [diff] [review]
patch, updated to trunk
Attachment #330287 - Attachment is obsolete: true
Attachment #333928 - Flags: ui-review?(beltzner)
Attachment #330287 - Flags: ui-review?(beltzner)
(Assignee)

Updated

9 years ago
Blocks: 450743
The more I think about this, the more I think that my comment makes sense. Consider the scenario:

 - reading a web page
 - cmd/ctrl+click links to open them in background tabs
 - flip with cmd-tab over to those newly opened tabs

Where it doesn't make sense, though, sadly, is the following scenario

 - reading a web page
 - cmd/ctrl+click links to open them in background tabs
 - flip with cmd-tab to get back to previous tab; whoops, now I'm somewhere else

Boriss: you've been doing a lot more thinking about the MRU vs. not-MRU issue, as well as the use cases around this feature. Any comments?
This issue is definitely not cut & dry, because as we've seen users run into both of those cases Beltzner mentioned - one where you're putting new items on the path in front of you ("these are next") and one where you're throwing them to the side ("I'll look at these later").

My gut is to agree with Beltzner & Dao that these new tabs should be added as if they were given focus.  The reason is I think it's more consistent than the alternative.  If new tabs are added to MRU, MRU means "any tab I recently used, and "used" is any action.  If new tabs are not added, you're creating two different kinds of "used" - visited and created - and there's no visual or interaction affordance to show the difference.  

That said, perhaps we should test this in the future. 
Assignee: dao → nobody
Status: ASSIGNED → NEW
(Assignee)

Updated

9 years ago
Assignee: nobody → dao
(Assignee)

Updated

9 years ago
Status: NEW → ASSIGNED
(Assignee)

Updated

9 years ago
Attachment #333928 - Flags: review?(gavin.sharp)
Attachment #333928 - Flags: review?(gavin.sharp) → review+
Comment on attachment 333928 [details] [diff] [review]
patch, updated to trunk

Boriss is convincing.
(Assignee)

Updated

9 years ago
Attachment #333928 - Flags: ui-review?(beltzner) → review?(gavin.sharp)
Attachment #333928 - Flags: review?(gavin.sharp) → review+
(Assignee)

Updated

9 years ago
Keywords: checkin-needed
(Assignee)

Comment 5

9 years ago
http://hg.mozilla.org/mozilla-central/rev/a6a8f6d8080b
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3.1b1
verified fixed using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b1pre) Gecko/20081006 Minefield/3.1b1pre.
Status: RESOLVED → VERIFIED
Flags: in-litmus?
https://litmus.mozilla.org/show_test.cgi?id=7045 added to Litmus.
Flags: in-litmus? → in-litmus+
You need to log in before you can comment on or make changes to this bug.