Beginning on October 25th, 2016, Persona will no longer be an option for authentication on BMO. For more details see Persona Deprecated.
Last Comment Bug 651456 - [css3-animations] Saving during CSS3 animations causes animations to stop
: [css3-animations] Saving during CSS3 animations causes animations to stop
Product: Core
Classification: Components
Component: CSS Parsing and Computation (show other bugs)
: Trunk
: x86_64 Windows 7
: P2 normal (vote)
: mozilla5
Assigned To: David Baron :dbaron: ⌚️UTC-7
: Jet Villegas (:jet)
: 651473 (view as bug list)
Depends on:
Blocks: 651473
  Show dependency treegraph
Reported: 2011-04-20 04:01 PDT by Danny Moules
Modified: 2013-12-27 14:36 PST (History)
10 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

patch (2.41 KB, patch)
2011-04-27 23:11 PDT, David Baron :dbaron: ⌚️UTC-7
bzbarsky: review+
jpr: approval‑mozilla‑aurora+
Details | Diff | Splinter Review

Description Danny Moules 2011-04-20 04:01:09 PDT
User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0a2) Gecko/20110419 Firefox/5.0a2
Build Identifier: Aurora (5.0a2)

Opening the Save File As.. dialog stops CSS3 animations. They do not restart if you cancel out of the dialog.

Reproducible: Always

Steps to Reproduce:
1. View page
2. Visit File -> Save Page As
3. Cancel out of dialog
Actual Results:  
Animation is stopped when dialog comes up, doesn't restart

Expected Results:  
Animation should continue when dialog is closed (and possibly whilst the dialog isn't doing anything?)
Comment 1 aravindm 2011-04-20 05:03:26 PDT
Mozilla/5.0 (Windows NT 6.1; rv:6.0a1) Gecko/20110419 Firefox/6.0a1

Works fine for me. 
Does the issue still occur if you start Firefox in Safe Mode?

How about with a new, empty profile?
Comment 2 Robert Utasi [:hunboy] 2011-04-20 05:20:11 PDT
Mozilla/5.0 (Windows NT 5.1; rv:6.0a1) Gecko/20110419 Firefox/6.0a1

I can confirm this issue, animation randomly stops. Scrolling, opening "view page source" etc. can cause this stop. Sometimes stops with no reason. (tested on clean safe mode also).
Comment 3 Danny Moules 2011-04-20 06:46:50 PDT
@aravindm Tried both. No benefit.
Comment 4 Danny Moules 2011-04-20 07:44:24 PDT
Hmm. Behaviour does NOT occur for the animation here:

...I blame SVG written for Chrome ;)
Comment 5 d 2011-04-20 07:55:38 PDT
The animation at has stopped twice for me, but that was before I realized that it was an issue. I don't remember what I did to make it happen, but I'm having trouble reproducing it now that I try.
Comment 6 Arjan 2011-04-21 01:47:42 PDT
Mozilla/5.0 (Windows NT 5.1; rv:6.0a1) Gecko/20110419 Firefox/6.0a1

I think i have found kinda reliable STR:

1. Open
2. View source
3. Drag the window to a position not covering the animation
4. (if all is correct, you now still have a animation. if not, refresh)
5. Drag the window to cover the animation, release mouse
6. Drag window back to not cover animation
7. Animation is now stopped (or go to step 5 again)
Comment 7 Danny Moules 2011-04-21 02:32:37 PDT
Tried Arjan's approach. Sometimes the animation stops when I first click down to drag. Sometimes the animation stops when I end the drag. Sometimes the animation does neither and only does it when I repeat the drag operation. Unable to get a consistent response. Speculation: Race condition?
Comment 8 Robert Utasi [:hunboy] 2011-04-21 12:59:39 PDT
philippe: i think it's not an internal/external css file problem, seems to me more rather processor usage and timer problem.

So shortly: ATAT sample sits massively into the processor, but dbaron's ping-pong not so hungry for processor-time. The situation is: when something happens which one reduces the processor-capacty for the mozilla-process where the animation runs with really high processor-usage, and the any event causes some delay, that basically disturbs the timer-syncing and animation stops. This event can come from the mozilla, like opening a new window, or scrolling etc. , but can come from outside, the other process sits temporarly to the core also, that causes also stopping.
And whats more - see virtualisation, now i can kill the animation from the base computer also by disturbing the virtual machine( as a process)'s processorusage, because that also causes delay inside the virual process.

a comment to Arjan's tipp: Now i can massively kill dbaron's sample too by resizing the window, because window-resizing also sits into the processor during happening and bothers the timer.

So i vote to: timer/syncing and processor capacity, and 1 vote to Danny's tipp: Race condition
Comment 9 David Baron :dbaron: ⌚️UTC-7 2011-04-21 13:55:56 PDT
I wonder if this could be related to the issue in bug 650469.
Comment 10 David Baron :dbaron: ⌚️UTC-7 2011-04-21 15:32:12 PDT
Could this be another problem with precise timers?
Comment 11 Boris Zbarsky [:bz] (still a bit busy) 2011-04-21 17:23:57 PDT
Hmm.  That seems unlikely....
Comment 12 David Baron :dbaron: ⌚️UTC-7 2011-04-22 12:58:43 PDT
Has anybody seen this on a non-Windows platform?
Comment 13 Robert Utasi [:hunboy] 2011-04-22 14:17:39 PDT
I can not reproduce this bug at all on fedora with this ua:

Mozilla/5.0 (X11; Linux i686; rv:6.0a1) Gecko/20110422 Firefox/6.0a1

it's windows only at me (no macosx for testing)
Comment 14 philippe (part-time) 2011-04-22 17:00:36 PDT
(In reply to comment #12)
> Has anybody seen this on a non-Windows platform?

This bug I can't repro on OS X 10.6 with the most recent nightly build(s). All the cases of stopped animation are bug 651473 on my side.
Comment 15 David Baron :dbaron: ⌚️UTC-7 2011-04-22 22:43:51 PDT
Using the steps in comment 6, I see this on Windows.
Comment 16 d 2011-04-23 03:37:43 PDT
I've been able to stop the animation a couple of times on OS X just by dragging and selecting text in different ways on It's not a reliable way of making it happen, but it does sometimes.
Comment 17 Robert Utasi [:hunboy] 2011-04-23 05:51:37 PDT
( In reply to Bug 651473 comment #7 )
> How fast a machine do the people who (a) do see this and (b) don't see this
> have?

I use virtualisation. The base hw is 2.4G core2-quad so the virt one should be 1.5G around. fsb+memory 1160. I have mb integrated videocard, and virtual videocard too the processor itself.

on winxp vm the ATAT should walk for hours with 2 cores standalone if nothing bisturbs the vm from the base computer. When i reduce the affinity to only 1 core at the basecomputer for the vm, the atat breaks and stops in 3-4secs.

however on linux - with only 1 core - works and nothing can break that.
Comment 18 David Baron :dbaron: ⌚️UTC-7 2011-04-23 10:33:02 PDT
(In reply to comment #15)
> Using the steps in comment 6, I see this on Windows.

Or rather, I saw it the first time I tried.  But then I put some additional code in to debug what was happening, and haven't managed to get it to happen again.
Comment 19 Robert Utasi [:hunboy] 2011-04-23 12:10:42 PDT
David: to use this reduction (comment 17) on your testcase also, that stops also between 5 secs and 2mins. It seems some type of bordercase in my configuration with  these settings. Firstly it seems it handles the suffered delay by jumping to the real-time state, but finally at the last jump it stops. I cannot do more scaling perhaps scaling by percentage the processorusage, on this vm, its vmware workstation and not esxi.
Comment 20 David Baron :dbaron: ⌚️UTC-7 2011-04-27 13:47:43 PDT
So I found it easy to repro this bug on Windows in a nightly build; I'm building a local opt build now to see whether I can repro in that.
Comment 21 David Baron :dbaron: ⌚️UTC-7 2011-04-27 22:57:04 PDT
I do see this in a locally-built opt build (using the steps in comment 6).
Comment 22 David Baron :dbaron: ⌚️UTC-7 2011-04-27 23:11:31 PDT
Created attachment 528801 [details] [diff] [review]

I'm an idiot.  This was stupid.

In any case, I'm still linking libxul on my Windows machine, but I confirmed that the test fails exactly as I'd expect without the patch.
Comment 23 David Baron :dbaron: ⌚️UTC-7 2011-04-27 23:29:26 PDT
I've also now confirmed that:

 * on my Windows opt build, the patch makes it so I can no longer reproduce this bug (whereas without the patch, I could reproduce reliably on that build)

 * the mochitest passes with the patch (in addition to failing without it)
Comment 24 David Baron :dbaron: ⌚️UTC-7 2011-04-27 23:37:41 PDT
Once I get review, I intend to request Aurora approval, for the following reasons:

 * Now that bug 649400 is fixed, this (and bug 651473, which is almost certainly a duplicate of this one) was the only known css3-animations bug that made me concerned about whether we could ship animations

 * This is a really trivial fix for a stupid mistake in the animations code (and entirely isolated to the animations code).  Basically, each time we recomputed an element's animation style due to the clock advancing, we set a boolean saying whether we'd need to refresh animations for this element due to future clock advances (so we could avoid doing this recomputation work for animations that have completed or that are paused).  We did this by, at the start of the recomputation, resetting the "needs refreshes" flag to false, and then as we loop through the animations to recompute the style, setting it to true if there was an unpaused and uncompleted animation.  The problem is that the reset was outside the test for "we've already computed our style for this timestamp", so if we got two refreshes at the same time stamp (I suspect a restyle triggered from another refresh observer and then our own refresh notification), we'd end up with this flag set to false and stuck there until we got some other style change to start things up again.  The patch just moves the reset inside the if() that it should have been inside in the first place.
Comment 25 Boris Zbarsky [:bz] (still a bit busy) 2011-04-28 05:00:52 PDT
Comment on attachment 528801 [details] [diff] [review]

Comment 26 David Baron :dbaron: ⌚️UTC-7 2011-04-28 10:26:39 PDT
Comment 27 David Baron :dbaron: ⌚️UTC-7 2011-04-28 15:46:30 PDT
Comment 28 David Baron :dbaron: ⌚️UTC-7 2011-04-29 08:49:41 PDT
If you have a chance, could those of you who saw this retest with today's build (either Nightly or Aurora) to confirm that it is fixed?
Comment 29 Robert Utasi [:hunboy] 2011-04-29 09:21:20 PDT
I've upgraded 2.5 hours ago, reduced the vm and animation still works, I can not reproduce the bug anymore anyhow. not in reduction, not with opening paralel windowses etc.
Comment 30 David Baron :dbaron: ⌚️UTC-7 2011-04-29 20:36:23 PDT
*** Bug 651473 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.