Animation for closing the last tab has a slight delay near the end when the tab bar overflows

RESOLVED FIXED in Firefox 12

Status

()

Firefox
Tabbed Browser
RESOLVED FIXED
6 years ago
4 years ago

People

(Reporter: glandium, Assigned: dao)

Tracking

(Blocks: 1 bug, {polish})

Trunk
Firefox 12
polish
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [snappy])

Attachments

(2 attachments)

(Reporter)

Description

6 years ago
STR:
- open plenty of tabs (enough to have the scroll buttons showing up)
- close the right-most tab
- in slow motion, what you would see is the animation happening (other tabs moving to the right) until some point at less than an icon size left to move, the animation stops for a few moments and then jumps to the final position.

This is not completely noticeable, but it so happens that on a firefox-as-xulrunner-app setup, the animation actually stops for a little while in the not quite finished position, and then the following message shows up:
ASSERT: Giving up waiting for the tab closing animation to finish (bug 608589)
Stack Trace: 
0:([object XULElement],[object XULElement],0)

But I think the latter is related to another error i get in the console related to telemetry failure on onxbltransitionend.

That error put aside, the slight delay can be seen on current (vanilla) beta and aurora (didn't test other builds)
(Reporter)

Comment 1

6 years ago
I confirm the error message is due to telemetry.
(Assignee)

Updated

6 years ago
Assignee: nobody → dao
Blocks: 596954
Keywords: polish
OS: Linux → All
Hardware: x86_64 → All
Whiteboard: [snappy]
Version: 8 Branch → Trunk
(Reporter)

Comment 2

6 years ago
Adding "return" there:
http://mxr.mozilla.org/mozilla-central/source/browser/base/content/tabbrowser.xml#3266

allows to see where the animation stops. That being the transitionend event suggests the transition does not actually cover the expected animation.
Mike, there is bug 708912 that I've filed some time ago. We can close this or that as duplicate.
(Reporter)

Comment 4

6 years ago
I think bug 708912 is a different issue. That one seems to be about the whole animation being slow. This one is that the animation is incomplete and then jumps to final position.
(In reply to Mike Hommey [:glandium] from comment #4)
> This one is that the animation is incomplete and
> then jumps to final position.

This is what I meant with "animation deferred" :D. Closing that as this is more clear.
Duplicate of this bug: 708912
The error ("ASSERT: Giving up waiting...") periodically appears in Firefox 10b1 (build from http://hg.mozilla.org/releases/mozilla-beta/rev/c130e43aa4b5).

Exact steps to reproduce are unknown, but they are _different_ from steps described in the bug description (comment 0) which don't cause the error for me.
(Assignee)

Comment 8

6 years ago
Created attachment 584229 [details] [diff] [review]
patch

The tab contents prevent the tab from shrinking down to zero. We can just completely hide that stuff, we don't really need the opacity transition.
Attachment #584229 - Flags: review?(mak77)
(Assignee)

Comment 9

6 years ago
I immediately saw the positive effect of this patch on Linux. On Windows, the transition was so choppy that it was hard to tell a difference, until I disabled hardware acceleration... Bug 633157 is quite bad.
(Assignee)

Updated

6 years ago
Blocks: 593680
No longer blocks: 596954
(Assignee)

Updated

6 years ago
Attachment #584229 - Flags: review?(ehsan)
Comment on attachment 584229 [details] [diff] [review]
patch

Review of attachment 584229 [details] [diff] [review]:
-----------------------------------------------------------------

Looking at the reason the animation was added, there should be no problem in testing this change live, and eventually re-evaluate later.
Is it noticeable that these contents appear at once when the tab opens? My system is likely too fast to notice the difference.
Attachment #584229 - Flags: review?(mak77) → review+
(Assignee)

Updated

6 years ago
Attachment #584229 - Flags: review?(ehsan)
(Assignee)

Comment 11

6 years ago
(In reply to Marco Bonardo [:mak] from comment #10)
> Is it noticeable that these contents appear at once when the tab opens? My
> system is likely too fast to notice the difference.

They don't appear immediately, since we also have a transition for the whole tab's opacity.
(Assignee)

Comment 12

6 years ago
http://hg.mozilla.org/integration/mozilla-inbound/rev/0e7bacdbb8fc
Target Milestone: --- → Firefox 12
https://hg.mozilla.org/mozilla-central/rev/0e7bacdbb8fc
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED

Comment 14

6 years ago
(In reply to Dão Gottwald [:dao] from comment #8)
> Created attachment 584229 [details] [diff] [review]
> patch
> 
> The tab contents prevent the tab from shrinking down to zero. We can just
> completely hide that stuff, we don't really need the opacity transition.

what about tab borders?
why not to hide the borders to ?
(Assignee)

Comment 15

6 years ago
(In reply to onemen.one from comment #14)
> (In reply to Dão Gottwald [:dao] from comment #8)
> > Created attachment 584229 [details] [diff] [review]
> > patch
> > 
> > The tab contents prevent the tab from shrinking down to zero. We can just
> > completely hide that stuff, we don't really need the opacity transition.
> 
> what about tab borders?
> why not to hide the borders to ?

I don't see that borders are a problem here. If you do, please file a bug.
(Assignee)

Updated

6 years ago
Summary: Animation for closing a tab has a slight delay near the end when there is a lot of tabs → Animation for closing the last tab has a slight delay near the end when the tab bar overflows

Comment 16

6 years ago
I'm using a Win64 2011-12-30 nightly (0d684c34d1e4) which is supposed to have this fix, if I understand correctly, and I still get the problem, easily and every time.

Toggling HW acceleration on and off doesn't make any difference. The rest of the animations are smooth, but there's a very noticeable pause at the end of the tab closing one, when the closed tab has disappeared, before the empty space is removed.

The pause is long enough to make taking an screenshot easy; I'm attaching one.

Comment 17

6 years ago
Created attachment 584969 [details]
(Screenshot for comment 16 - this is the state when there's a pause)
(Assignee)

Comment 18

6 years ago
(In reply to mozbugz from comment #16)
> I'm using a Win64 2011-12-30 nightly (0d684c34d1e4) which is supposed to
> have this fix, if I understand correctly, and I still get the problem,
> easily and every time.
> 
> Toggling HW acceleration on and off doesn't make any difference. The rest of
> the animations are smooth, but there's a very noticeable pause at the end of
> the tab closing one, when the closed tab has disappeared, before the empty
> space is removed.
> 
> The pause is long enough to make taking an screenshot easy; I'm attaching
> one.

Can you reproduce this in a new profile? If so, please file a bug on it.

Comment 19

6 years ago
No, I can't. Looks like it was an userChrome.css issue.

Sorry about the noise, I really should have checked that first.

Updated

6 years ago
Blocks: 715071

Comment 20

6 years ago
filled bug 715071 as a regression of this bug
(Assignee)

Updated

5 years ago
Duplicate of this bug: 587842
You need to log in before you can comment on or make changes to this bug.