Closed Bug 713287 Opened 12 years ago Closed 12 years ago

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

Categories

(Firefox :: Tabbed Browser, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
Firefox 12

People

(Reporter: glandium, Assigned: dao)

References

Details

(Keywords: polish, Whiteboard: [snappy])

Attachments

(2 files)

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)
I confirm the error message is due to telemetry.
Assignee: nobody → dao
Blocks: 596954
Keywords: polish
OS: Linux → All
Hardware: x86_64 → All
Whiteboard: [snappy]
Version: 8 Branch → Trunk
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.
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.
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.
Attached patch patchSplinter Review
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)
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.
Blocks: 593680
No longer blocks: 596954
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+
Attachment #584229 - Flags: review?(ehsan)
(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.
https://hg.mozilla.org/mozilla-central/rev/0e7bacdbb8fc
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
(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 ?
(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.
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
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.
(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.
No, I can't. Looks like it was an userChrome.css issue.

Sorry about the noise, I really should have checked that first.
Blocks: 715071
filled bug 715071 as a regression of this bug
You need to log in before you can comment on or make changes to this bug.