Open Bug 663395 Opened 13 years ago Updated 2 years ago

tabstrip animation is hurty when traversing a large number of tabs

Categories

(Firefox :: Tabbed Browser, defect)

defect

Tracking

()

REOPENED

People

(Reporter: dietrich, Unassigned)

References

(Depends on 1 open bug)

Details

Attachments

(1 file, 1 obsolete file)

STR:

1. have 100 tabs open
2. activate the rightmost tab
3. go to an app tab and click a link

Expected: the new tab to the right of the app tabs is instantly created and focused.

Actual: wait for the animation to finish speeding past all your tabs, feel slightly dizzy, finally arrive at the new tab.

We should either suspend animations when it's clear we'll be traversing huge amounts of tabs, or fix animations to be much much faster (though, this won't help the dizziness).
Assignee: nobody → dao
OS: Mac OS X → All
Hardware: x86 → All
Attached patch patch (obsolete) — Splinter Review
I don't think we want to arbitrarily disable the animation, but we also shouldn't scroll when it doesn't really make sense in the first place. With this patch, we put tabs opened from pinned tabs at the end of the tab strip, as we can't consistently open them next to the pinned tab anyway (because other pinned tabs can be in the way).
Attachment #547087 - Flags: ui-review?(faaborg)
>we also shouldn't scroll when it doesn't really make sense in the first place

If we are putting tabs at the end of the strip when opened from app tabs, then wouldn't we always scroll?  The advantage of scrolling is that it helps the user build a mental model of where there tabs are.  The disadvantage is the amount of time, and dizzy factor.  I think ideally we should just make long scroll animations faster (mental model + reasonable time > dizzy).
(In reply to comment #2)
> If we are putting tabs at the end of the strip when opened from app tabs,
> then wouldn't we always scroll?

In my personal experience, the tab strip is usually scrolled to the end when an app tab is selected. Selecting an app tab doesn't scroll the tab strip back to the start, because it's not part of the scrollable area.
>With this patch, we put tabs opened from pinned tabs at the end of the tab strip

right, I thought we were already doing that.
Attachment #547087 - Flags: ui-review?(faaborg) → ui-review+
Attachment #547087 - Flags: review?(gavin.sharp)
Comment on attachment 547087 [details] [diff] [review]
patch

Hrm, is it a bug that we don't do the owner setting stuff if !insertRelatedAfterCurrent? I don't fully understand why we mess with _lastRelatedTab's owner in multiple places, or why we avoid setting the new tab's owner if there is a _lastRelatedTab.
(In reply to comment #5)
> Hrm, is it a bug that we don't do the owner setting stuff if
> !insertRelatedAfterCurrent?

yes

> I don't fully understand why we mess with
> _lastRelatedTab's owner in multiple places, or why we avoid setting the new
> tab's owner if there is a _lastRelatedTab.

Because this determines which tab will be selected when closing these tabs.
Attached patch patchSplinter Review
moved the pref check
Attachment #547087 - Attachment is obsolete: true
Attachment #547087 - Flags: review?(gavin.sharp)
Attachment #547182 - Flags: review?(gavin.sharp)
(In reply to comment #6)
> Because this determines which tab will be selected when closing these tabs.

Yes, I know that's the purpose of .owner in general, but it's not clear to me why the _lastRelatedTab stuff needs special behavior in terms of ownership/closing.
Attachment #547182 - Flags: review?(gavin.sharp) → review+
http://hg.mozilla.org/mozilla-central/rev/ef79a5b41697
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Summary: tabstrip animation is hurty when traversing a large number of tabs → put tabs opened from pinned tabs at the end of the tab strip
Target Milestone: --- → Firefox 8
This is entirely the wrong direction — and doing this to work around the fact that scrolling tabs is slow makes no sense.

We should always open a new tab — whether spawned from a link or just as a new tab with Ctrl/Cmd-T — right next to the current one. Opening a new tab at the end of the tab strip changes your current context, which is undesirable. The logic of "we don't know whether the new tab is related to the tab you're looking at if you hit Ctrl-T, so we put it at the end" is broken, since the likelihood of it being related is much larger than zero. The same goes for app tabs.

The lone exception to this is if you click the New Tab button in the tab strip, in which case you are visually at the end of the row, and you'd expect it.

Faaborg knows (and I believe, agrees ;) with that design pattern, so I'm confused at why he would give this patch a ui-r+ unless he was confused at what it actually does.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(In reply to comment #11)
> This is entirely the wrong direction — and doing this to work around the
> fact that scrolling tabs is slow makes no sense.

We could scroll faster, but even if it was instant, it would still be disruptive. If it's true that the tab strip is usually scrolled to the end, it would jump to the opposite end of the tab strip whenever you click a link in an app tab.

> We should always open a new tab — whether spawned from a link or just as a
> new tab with Ctrl/Cmd-T — right next to the current one.

App tabs (multiple app tabs in particular) break this concept, as they aren't part of the scrollable area. Only an app tab can really be opened next to an app tab.
> In my personal experience, the tab strip is usually scrolled to the end when an
> app tab is selected.

That's certainly not the case for me.... In my case it's been nearly always scrolled to the beginning, because I'd just come from a tab that opened from the app tab.

With the changes in this bug, what happens is that once I've opened a few tabs from the app tab actually going and reading them in order is a huge pain.
(In reply to comment #13)
> > In my personal experience, the tab strip is usually scrolled to the end when an
> > app tab is selected.
> 
> That's certainly not the case for me.... In my case it's been nearly always
> scrolled to the beginning, because I'd just come from a tab that opened from
> the app tab.

That might work when app tabs are in the center of your workflow -- for me they are only part of it. Supposedly this is true for Dietrich as well, otherwise he wouldn't have complained about this.
How should we handle a bookmark opened in a new tab?
How should we handle links from external applications?
> That might work when app tabs are in the center of your workflow

In the window I have the app tab in, it _is_ in the center of my workflow.  All I have in that window is the app tab (an RSS feed) and the things I want to read that were linked from it.
I didn't say it wasn't the center of your workflow. I'm saying there are other workflows too.
Sure.  I understand that.
Dietrich's issue was with the time to scroll, not the placement.
I half agree with comment #11, here's my take on this:

The two things we want to leverage are:
1) keeping activities grouped together
2) creating a general old to new organization of the tab strip itself

So to achieve both of these we:

1) open command-t and + button tabs at the end of the strip (these are new tabs, in the newer, fresher part of the strip)
2) open command-click links directly next to the tab that created them (these are obviously related and we want them to be grouped)

app tabs are kind of a boundary case, since we can't group the new tabs along with them, so we would have to decide to either put the tabs they create at the start or at the end.  Since the start is old-ish, and the end is new-ish, I think it makes more sense to create them at the end.  Anecdotally this seems to also cut down on the amount of scrolling, since people seem to be spending more time at the new end of their tab strip than the old end.
We can't group things with an app tab only if there are multiple app tabs, right?
In particular, I'd really like to see if we can figure out a way to address the use case from comment 13 paragraph 2.  Before the changes in this bug, all I had to do was open my links from the app tab, then hit Accel-pgdown in order to read them.

Now I sort of have the choice of hitting Accel-pgup to read them in reverse order or spending a bunch of time hunting for them on the tabstrip....
(In reply to comment #21)
> In particular, I'd really like to see if we can figure out a way to address
> the use case from comment 13 paragraph 2.  Before the changes in this bug,
> all I had to do was open my links from the app tab, then hit Accel-pgdown in
> order to read them.

One way to address it would be to keep the first descendant tab at the top of the MRU-ordered list for Ctrl-Tab.
You're overthinking this.

Tabs should open right next to the current tab. App tabs should open right next to the app tabs area. Simple, predictable, and doesn't assume anything about intent or context. Even Safari got this right with Safari 5.

Please revert the current patch, it's worse than the existing (admittedly slow because of the animation) behavior.
With the current patch, you'd have an even more convoluted behavior than the current (already overly complex) behavior:

1. If the tab is related: open right next to the current tab
2. If you can't determine whether the tab is related: open it at the end

…then this patch adds to that:

3. If the tab is related (since the link was opened from the app tab), but happens to be an app tab: open at the end

Making tab behavior even more complicated isn't moving in the right direction.
(In reply to comment #24)
> …then this patch adds to that:
> 
> 3. If the tab is related (since the link was opened from the app tab), but
> happens to be an app tab: open at the end

That should read "[…] but happens to be an launched from an app tab: open at the end"
(In reply to comment #23)
> You're overthinking this.
> 
> Tabs should open right next to the current tab. App tabs should open right
> next to the app tabs area. Simple, predictable, and doesn't assume anything
> about intent or context. Even Safari got this right with Safari 5.
> 
> Please revert the current patch, it's worse than the existing (admittedly
> slow because of the animation) behavior.

I find the change in behaviour surprising as well, and after several days living with it still prefer the old behaviour, though I appreciate that my experience is anecdotal, not data.

As a process point, this bug is in a bad state now. If it's REOPENED, we need the patch backed out. If the patch is staying in, this bug isn't REOPENED. This bug got ui-r and review, so I don't fault the initial landing, but given that the ui-r is now under considerable debate, I don't think we can treat the current landing as an improvement and, like a late-breaking r- or sr-, I think we should back out.

Who can do that today?

[cc'ng shaver since he also asked me about this]
Assignee: dao → nobody
Summary: put tabs opened from pinned tabs at the end of the tab strip → tabstrip animation is hurty when traversing a large number of tabs
Target Milestone: Firefox 8 → ---
+1 that the tab should show up at the far end (right/newer) of the tab strip.  Pref switch "browser.tabs.insertPinnedAtEnd"?

or collect stats where people spend most of their time on, front or back of tab strip?
(In reply to henry.fai.hang.chan from comment #28)
> or collect stats where people spend most of their time on, front or back of
> tab strip?

We could, but we'd just discover that there's a share of users who spawn most of their new tabs from app tabs, making their tab strip be scrolled to the start most of the time. We would know how big that share is, but what exactly would we conclude from that? It seems out of question that other than tabs opened from app tabs, there's nothing that would spontaneously scroll the tab strip to the start.
Depends on: 655445
> It seems out of question that other than tabs opened from app tabs, there's nothing that would spontaneously scroll the tab strip to the start.

I buy you but would the UX team like stats instead?
> With the current patch, you'd have an even more convoluted behavior than the current (already overly complex) behavior

Sorry I don't agree. Without the patch, you actually have three kinds of behavior.

Links in app tabs open at the start.
Links in normal tabs open next to them.
New Tabs open at the right.

If the user has one or more app tabs, even if the new tabs were at the start of the tabstrip, they still might not be 'grouped'; there may be one or two apptabs stuck in between.

If the user doesn't have many tabs there isn't a problem.  Having one or two apptabs stuck in between related tabs isn't THAT big deal (or is it?)

If the user has a lot of tabs it starts getting annoying to animate forward all the time.  And it gets extra time consuming that i have to frequently scroll to the end.

Newer tabs belong farther right.

With the patch, you only have two behaviors:
If the tabs can open next to each other, it opens on the right of the referring tab.
Otherwise it opens on the far right side of the tabstrip.

Simple.
> If the tabs can open next to each other, it opens on the right of the referring
> tab.

That behavior would imply that when there is only one app tab new tabs from it are opened next to it.  That's not what the patch does...
(In reply to Boris Zbarsky (:bz) from comment #32)
> > If the tabs can open next to each other, it opens on the right of the referring
> > tab.
> 
> That behavior would imply that when there is only one app tab new tabs from
> it are opened next to it.

Except that "next to it" still doesn't make as much sense as for a fixed element in relation to moving elements. As you scroll back to the end, they're not visually grouped anymore.
can we just have a pref please?
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: