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.
Created attachment 333928 [details] [diff] [review] patch, updated to trunk
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
Attachment #333928 - Flags: review?(gavin.sharp)
Comment on attachment 333928 [details] [diff] [review] patch, updated to trunk Boriss is convincing.
Attachment #333928 - Flags: ui-review?(beltzner) → review?(gavin.sharp)
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
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
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.