Closed
Bug 586347
Opened 14 years ago
Closed 9 years ago
investigate using transitionend rather than setTimeout in iQ.animate
Categories
(Firefox Graveyard :: Panorama, defect, P3)
Firefox Graveyard
Panorama
Tracking
(Not tracked)
RESOLVED
WONTFIX
Future
People
(Reporter: iangilman, Unassigned)
References
Details
(Whiteboard: b5)
Dao has suggested in bug 582023 that we should consider using transitionend rather than setTimeout in iQ.animate. This bug is to follow up on that suggestion. For starters, some background: iQ.animate accepts a completion function and guarantees that that function will be called once and only once upon completion (or cancellation) of the animation. In fact, "once and only once" is the more important requirement; it would be nice if it was exactly at completion of the animation, but it's okay for it to be close. We originally tried transitionend for this purpose, but ran into a number of issues. If I recall correctly, transitionend is sent for every property that is animating, so for iQ.animate calls that involve multiple properties (which is the majority case) we have to coalesce all of those events into a single completion. Worse, if a second animation starts before the first animation ends (not an unlikely case in our environment, and perfectly acceptable), we never get a transitionend for the first animation; it only arrives (once) after the second animation completes. This makes it extremely difficult to guarantee we will send a complete for each animation in a timely fashion. For these reasons we chose setTimeout. While the timing is not guaranteed to be exactly right, it'll be close enough, and more importantly, we can guarantee "once and only once". I'm certainly open to a better way, however. Thus this bug for discussion.
Updated•14 years ago
|
Whiteboard: b5
Comment 1•14 years ago
|
||
Mass moving all Tab Candy bugs from Mozilla Labs to Firefox::Tab Candy. Filter the bugmail spam with "tabcandymassmove".
Product: Mozilla Labs → Firefox
Target Milestone: -- → ---
Updated•14 years ago
|
QA Contact: tabcandy → tabcandy
Updated•14 years ago
|
Priority: -- → P3
Comment 3•9 years ago
|
||
Panorama has been removed from Firefox 45, currently in Beta and scheduled for release on March 7th. As such, I'm closing all existing Panorama bugs. If you are still using Panorama, you will see a deprecation message in Firefox 44, and when 45 is released your tab group data will be migrated to bookmarks, with a folder for each group. There are also a few addons offering similar functionality. See https://support.mozilla.org/en-US/kb/tab-groups-removal for more info. We're removing Panorama because it has extremely low usage (about 0.01% of users), and has a large number of bugs and usability issues. The cost of fixing all those issues is far too high to justify, and so we'll instead be focusing our time and energy on improving other parts of Firefox.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
Assignee | ||
Updated•9 years ago
|
Product: Firefox → Firefox Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•