327562 - Heuristics for tab ownership need tweaking

Status: RESOLVED FIXED

(Firefox :: Tabbed Browser, defect, P2)

Description

[Hixie (not reading bugmail)]

STEPS TO REPRODUCE
   1. Open several tabs, and select one in the middle to use as a test tab.
   2. Go to a page, such as GMail, that you'll be working from.
      Read an e-mail that asks you a question about goats.
   3. Ctrl+T (new tab).
   4. Do a search for "goat".
   5. Follow a link to learn about goats.
   6. Ctrl+W (close tab).
      CHECKPOINT A.
      Finish replying to that e-mail.
      Decide you're going to start something new.
   7. Ctrl+T (new tab).
   8. Alt+Home (home page), or go to, e.g.: http://damowmow.com/portal/
   9. Ctrl+Click a bunch of links to open tabs in background.
      You're now going to read those tabs.
  10. Ctrl+W (close tab).
      CHECKPOINT B.

EXPECTED RESULTS
   At checkpoint A, you should be at your test tab.
   At checkpoint B, you should be at your first newly opened tab.

ACTUAL RESULTS
   At both checkpoints, you are at your test tab.

Comment 1

[Mike Connor [:mconnor]]

Good call.  Once you start opening more tabs, its pretty obvious that you're not interacting with the tab on an interrupt basis, and it becomes another tab.

Taking (in the process of doing a bunch of tabbrowser work this weekend).  

Plzdontbitrotmekthx.

Comment 2

[Mike Schroepfer]

Mike - will this make the THurs night cutoff for A1?

Comment 3

[Mike Connor [:mconnor]]

I'm going to try, should be pretty straightforward.

Comment 4

[Mike Connor [:mconnor]]

Bah.  Moving to a2.

Comment 5

[Mike Connor [:mconnor]]

This is fixed as part of the larger tabbrowser patch for overflow, super-trivial, as it happens, will land after a2 when the other regressions are handled.

Comment 6

[Mike Connor [:mconnor]]

load-balancing tabbrowser stuff to sspitzer

Comment 7

[Mike Connor [:mconnor]]

gah.  s/.org/.com/!

Comment 8

[John Mellor (Jomel)]

Adding the bug this is being fixed in as a dependency.

This still won't work the other way round though:

STEPS TO REPRODUCE
   1. Open several tabs, and select one in the middle to use as a test tab.
   2. Go to a page, such as GMail, that you'll be working from.
      Read an e-mail that asks you a question about goats.
   3. Ctrl+T (new tab).
   4. Do a search for "goat".
   5. Open two links IN NEW TABS to learn about goats.
   6. Ctrl+W (close tab).
      CHECKPOINT A
   7. Read about goats
   8. Ctrl-W (close tab)
      CHECKPOINT B
   9. Read more about goats
  10. Ctrl-W (close tab)
      CHECKPOINT C
  11. Finish replying to that e-mail.

EXPECTED RESULTS
   At checkpoint A, you should be at the first tab about goats.
   At checkpoint B, you should be at the second tab about goats.
   At checkpoint C, you should be back at your test tab.

ACTUAL RESULTS
   With the fix, at checkpoints A and B you are at the appropriate tab about goats.
   But at checkpoint C you will be at the last tab instead of your test tab.

To do this properly we'd have to think of tabs as a kind of tree structure.
It could be done by keeping the owner attribute on tabs which you open new tabs from, but improving the heuristic for which tab to select after closing the active tab, trying to select (in order):
   1. A child of the current tab (tab with its owner set to this)
   2. A sibling of the current tab (tab with the same owner as this)
   3. The current tab's owner
   4. The tab to the right
   5. The tab to the left

Ideally when a tab is closed any child tabs should have their owner set to the closed tab's owner too, to keep things consistent.

(a downside is that this could cause a bit of jumping around of tabs, unless tabs are positioned relatively to their openers - consider perhaps the resulting vertical order in a tree widget if you forget about indentation)

Comment 9

[Adam Kowalczyk]

(In reply to comment #8)
The heuristics you presented seem very straightforward and have the advantage of covering all the reasonable use cases _by definition_, since a tree-like model is a natural reflection of relations between tabs. 

However, I fear that such heuristics are too advanced for users to figure them out without some kind visual indication. This model, if introduced, has to be reflected in the way tabs are ordered and/or separated in the tab bar. If we can't figure out a way to make the heuristics predictable for users, it will do more harm than good.

Comment 10

[John Mellor (Jomel)]

(In reply to comment #9)
> (In reply to comment #8)
> However, I fear that such heuristics are too advanced for users to figure them
> out without some kind visual indication. This model, if introduced, has to be
> reflected in the way tabs are ordered and/or separated in the tab bar.
> 

I agree that with the current appearance this would not be very intuitive, and it would probably require some creative UI and usability testing.
I am (slowly) working on an extension offering this, which should help see how users react.
A few of my current UI ideas include:
 * coloring tabs differently depending on how far down the heirarchy the tab is, and also depending on the tab's root node (e.g. one could affect hue, the other lightness in the hsl color scheme)
 * variable height top border to show how far down the hierarchy a tab is
 * arrows (or side borders) on the tabs to indicate which way focus will go after closing it
 * more radical but most effective: actually have tabs as a vertical tree (with increasing screen sizes this makes more and more sense)

Comment 11

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

How do we feel about tabs from external links? Presently they're treated as if they were opened *from* the currently focused tab.

My feeling is that they don't match the intent of the heuristic, and shouldn't be treated as if they were child links.

Comment 12

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

(In reply to comment #11)
> How do we feel about tabs from external links? Presently they're treated as if
> they were opened *from* the currently focused tab.
> 
> My feeling is that they don't match the intent of the heuristic, and shouldn't
> be treated as if they were child links.
> 

In SeaMonkey we don't track tab ownership when you click an external link (see bug 327873 for what exactly we did and a tiny bit of discussion about why).

Comment 13

[Mike Connor [:mconnor]]

if you open an external link, then close that tab, do you want to go back to where you were? or to the next tab?  the current behaviour optimizes for the former, which I think is correct in that case.

Comment 14

[Adam Kowalczyk]

(In reply to comment #10)
> A few of my current UI ideas include:
>  * coloring tabs differently depending on how far down the heirarchy the tab
> is, and also depending on the tab's root node (e.g. one could affect hue, the
> other lightness in the hsl color scheme)
>  * variable height top border to show how far down the hierarchy a tab is
>  * arrows (or side borders) on the tabs to indicate which way focus will go
> after closing it
>  * more radical but most effective: actually have tabs as a vertical tree (with
> increasing screen sizes this makes more and more sense)
The last one would be great for an extension that places the tab bar vertically on the side of the screen.

These are some interesting ideas (I thought about some of them myself) but I think most of them would be an overkill. Selecting the correct tab when closing tabs is a nice thing but it's not an essential part of tabbed browsing. As it is only an extra, I don't think it is worth a significant overhaul of the UI, including changing colors, shifting tabs etc. The visualization of the heuristics is best kept lightweight and uninvasive. Users shouldn't be reminded of the ownership structure, the system must be purely intuitive. 

Here's my take on this.

Perhaps grouping related tabs is enough. Consider the following example of how things look if child tabs are opened to the right of the currently selected tab:

(A, B, C mark level in hierarchy; 1, 2, 3 mark subsequent tabs on that level)

[...]__[Tab A]__[Tab B1]__[Tab B2]__[Tab C1]__[Tab C2]__[Tab B3]__[...]

When any of the tabs is closed, focus is moved to an adjacent tab, either the left-hand or the right-hand one. This doesn't make the behavior 100% predictable but maybe this relatively small inconsistency is acceptable. It could be worked around by some subtle indication, along the lines of one of the Jomel's ideas. BTW, the current heuristics (focusing the parent tab only if no switching was made) are not anymore predictable than that, as they may cause some random tab on the opposite end of the tabstrip to be focused and the "only if no switching was made in between" condition in practically unfathomable.

The huge advantage of this solution is that it's extremely lightweight in terms of the UI. It is enclosed in one change: to open new tabs to the right of the currently selected one.

Comment 15

[John Mellor (Jomel)]

(In reply to comment #14)
> These are some interesting ideas (I thought about some of them myself) but I
> think most of them would be an overkill.

Agreed, those ideas are better suited to extensions. But that doesn't mean a subtle yet logical approach isn't possible. Opening new tabs next to the current one would single-handedly make things obvious, and be quite a lot more intuitive once users got past the initial surprise, as opposed to the tab ownership system that is likely to catch users off-guard even once they learn it. [opening new tabs to the right of current is bug 161836 incidentally].
Then the 'tree-based' heuristic I suggested would only ever shift focus to a neighbouring tab, minimising confusion, and being a more accurate model it would almost always be the one you wanted anyway, hence acting more transparently (the tab close icon could always subtly show the direction on hover if deemed necessary).

Comment 16

[(not reading, please use [e-mail] instead)]

the original issue that hixie's reported appears fixed (on trunk and branch) now that bug #318168 has landed.

I believe this change in mconnor's patch fixed this:

http://lxr.mozilla.org/seamonkey/source/toolkit/content/widgets/tabbrowser.xml#1086

1086    // if we're adding tabs, we're past interrupt mode, ditch the owner
1087    if (this.mCurrentTab.owner)
1088      this.mCurrentTab.owner = null;

but I will double check before marking this bug as fixed.

Comment 17

[(not reading, please use [e-mail] instead)]

yes, it was mconnor's change (that I pointed to in comment #16) that changed this behavior and fixed the original bug that hixie reported.

this change was already checked into trunk and branch.

see also bug #339036, for another open bug about tab ownership.