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)

defect

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.
Depends on: 582023
Whiteboard: b5
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: -- → ---
QA Contact: tabcandy → tabcandy
Priority: -- → P3
Punting to the future.
Target Milestone: --- → Future
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
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.