565549 - Opening tabs at the end when new and next to when context-triggered is confusing — consolidate

Status: NEW

(Firefox :: Tabbed Browser, defect)

Description

[John Wayne Hill (UX Intern)]

(Note: this is filed as part of the “Paper Cut” bugs — we assume that there may be multiple existing bugs on this. Please make them block this bug, and we will de-dupe if they are indeed exactly the same. Thanks!)

To reproduce:
1. Start Firefox, open multiple tabs
2. Open a new blank tab
3. Open a context-triggered tab

Recommendation:
Always open tabs next to current tab or at the end of the tab bar. Simple is better.

Comment 1

[Mike Beltzner [:beltzner, not reading bugmail]]

An interesting assertion, and I suggest reading up on bug 465673 to get some background as to why we've chosen the existing behaviour.

Paul O'Shannessy has also filed some follow up bugs on the heuristic to make it a little more robust; perhaps he'll add references to those here if he gets a moment.

While I agree that simpler is usually better, I'm not sure that's universally the case here, but could be convinced. We're also missing a proposal: which do you think is the universally better option? Next to the current tab? Should we continue to "stack" background-opened tabs to the right such that you get 0 1 2 3 4 instead of 0 4 3 2 1 ?

Comment 2

[Ian Pottinger]

The two things that have always bugged me about Firefox's tab behaviour are that you get 0 1 2 3 4 instead of 0 4 3 2 1 and that closing a tab selects the tab to the right rather than the left.

I think that 0 4 3 2 1 is simpler to understand, more predictable. Selecting, the tab to the left moves you back towards the original tab (0) rather than away from it.

Comment 3

[David Regev]

The new behaviour is indeed awesome but confusing. In bug 540125 comment 3, I gave a suggestion that will alleviate much of this confusion: indicate the “tab group” visually, so you immediately know where a new tab will be spawned. Here is what I suggested:

Say I have three tabs open:
    A b c
(where capitalization indicates the active tab). Now, if I open three new
background tabs, I get:
    A d e f b c
This can get confusing, since the only way to know where the next tab will open
is to remember. The solution is to set a property for each tab in the active
tab group. That would allow those tabs to be styled, such as by a different
background colour. So, in our example, I start off with the following tabs:
    [A] b c
(where the square brackets indicate the active tab group). Opening three new
tabs yields the following:
    [A d e f] b c
This makes it clear that all the highlighted tabs are related and, more
importantly, it is now obvious where the next tab will be opened: right after
f.
If I now switch to d, the active tab group resets to just one tab again:
    a [D] e f b c
Again, where the next new tab will appear remains obvious (after D).

A solution to alleviate the confusion further is to highlight unread tabs (bug 209179), similar to how Windows highlights unread windows in the taskbar. That feature would make sure you don’t lose track of which tabs you haven’t read when they’re all interspersed in the tab bar, due to the Tabs Open Relative functionality.

Comment 6

[Thaddee Tyl [:espadrine]]

IIUC, comments 1 thru 3 are no longer relevant in the current browser, in which Ctrl+click on links now open at the end of the tab list at the right of the current tab, since this patch: <https://bugzilla.mozilla.org/show_bug.cgi?id=465673#c110>.

So the focus of this bug should specifically be about making the default behavior of Ctrl+T match that of Ctrl+click or middle-click on the + "new tab" button at the top right of the tab bar, as specified in this patch <https://bugzilla.mozilla.org/show_bug.cgi?id=528005#c73>.
It opens a tab at the right of the current tab list.

It would be interesting to know what the public at large would prefer, since the competition does not have that behavior.
Intuitively, I feel like most would favor "open at right of tab list".
Ideally, a poll with two explanatory gifs comparing the Ctrl+T behaviors may give an idea.

The "open at end of tab list" is incidentally a bit less confusing in Google Chrome because they always show all of the tabs.
In Firefox, if some tabs are invisible, you can be thrown all the way to the right when creating a new tab.

If most users organize their tabs on the tab bar by theme, the current behavior breaks that by creating a tab meant to be related to the current tab after tabs of a different theme.
Eg. if we are on A1 with [A1] A2 B1 B2 B3 (with A and B two themes), and perform Ctrl+T to search for a subject related to the current tab, we end up with A1 A2 B1 B2 B3 [A3].

However, it is also true that maybe the user was away from the computer and just came back, and their intent with a Ctrl+T was to open a tab that is part of a brand-new theme.
In that case, with the old behavior, they get A1 A2 B1 B2 B3 [C1], which is fine.
With the "open at right of tab list" behavior, they get A1 A2 [C1] B1 B2 B3, which is also fine.

Overall, I feel like generalizing the behavior we have in <https://bugzilla.mozilla.org/show_bug.cgi?id=528005#c73> may be welcome.

Comment 7

[reescf]

Aside from the missing text, the current behaviour is the worst aspect of Quantum's behaviour. I have ridiculous numbers of tabs open and Firefox repeatedly throws me to the end of the final row of tabs. This makes it impossible to find where I was before, impossible to keep related tabs together and is extremely disorientating. To make matters worse, Firefox sometimes throws me to an earlier tab for reasons I've not yet figured out, when I'm trying to visit somewhere new in a new, blank tab.

There's nothing simple about being thrown from one place to another all the time. 

Could you not at least make this configurable so I can choose to always have tabs open to the right of the current one?

Comment 10

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 4 duplicates.
:dao, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 11

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.