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)
Firefox
Tabbed Browser
Tracking
()
RESOLVED
FIXED
Firefox 12
People
(Reporter: glandium, Assigned: dao)
References
Details
(Keywords: polish, Whiteboard: [snappy])
Attachments
(2 files)
909 bytes,
patch
|
mak
:
review+
|
Details | Diff | Splinter Review |
3.23 KB,
image/png
|
Details |
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•12 years ago
|
||
I confirm the error message is due to telemetry.
Assignee | ||
Updated•12 years ago
|
Reporter | ||
Comment 2•12 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.
Comment 3•12 years ago
|
||
Mike, there is bug 708912 that I've filed some time ago. We can close this or that as duplicate.
Reporter | ||
Comment 4•12 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.
Comment 5•12 years ago
|
||
(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.
Comment 7•12 years ago
|
||
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•12 years ago
|
||
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•12 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•12 years ago
|
Assignee | ||
Updated•12 years ago
|
Attachment #584229 -
Flags: review?(ehsan)
Comment 10•12 years ago
|
||
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•12 years ago
|
Attachment #584229 -
Flags: review?(ehsan)
Assignee | ||
Comment 11•12 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•12 years ago
|
||
http://hg.mozilla.org/integration/mozilla-inbound/rev/0e7bacdbb8fc
Target Milestone: --- → Firefox 12
Comment 13•12 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/0e7bacdbb8fc
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Comment 14•12 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•12 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•12 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•12 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•12 years ago
|
||
Assignee | ||
Comment 18•12 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•12 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.
Comment 20•12 years ago
|
||
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.
Description
•