Closed Bug 651456 Opened 13 years ago Closed 13 years ago

[css3-animations] Saving during CSS3 animations causes animations to stop

Categories

(Core :: CSS Parsing and Computation, defect, P2)

Product:
Core
Component:
CSS Parsing and Computation
Platform:
x86_64
Windows 7
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla5
Tracking Flags:
Tracking Status
firefox5 + fixed

People

(Reporter: opensource, Assigned: dbaron)

References

(
URL
)

Details

Attachments

(1 file)

patch
2.41 KB, patch
bzbarsky
: review+
jpr
: approval-mozilla-aurora+
Details | Diff | Splinter Review 
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?)
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?
http://support.mozilla.com/en-US/kb/Safe+Mode

How about with a new, empty profile?
http://support.mozilla.com/en-US/kb/Basic+Troubleshooting#Make_a_new_profile.
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).

http://paulrouget.com/e/css3animations/
@aravindm Tried both. No benefit.
Hmm. Behaviour does NOT occur for the animation here:

http://dbaron.org/log/20110419-animations

...I blame SVG written for Chrome ;)
The animation at http://dbaron.org/log/20110419-animations 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.
Version: unspecified → Trunk
Blocks: 651473
Status: UNCONFIRMED → NEW
status-firefox5: --- → affected
tracking-firefox5: --- → ?
Ever confirmed: true
Summary: Saving during CSS3 animations causes animations to stop → [css3-animations] Saving during CSS3 animations causes animations to stop
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 http://dbaron.org/log/20110419-animations
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)
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?
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
I wonder if this could be related to the issue in bug 650469.
Could this be another problem with precise timers?
Hmm.  That seems unlikely....
Has anybody seen this on a non-Windows platform?
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)
(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.
Using the steps in comment 6, I see this on Windows.
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 dbaron.org. It's not a reliable way of making it happen, but it does sometimes.
( 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.
(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.
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.
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.
I do see this in a locally-built opt build (using the steps in comment 6).
Attached patch patch — — Splinter 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.
Assignee: nobody → dbaron
Status: NEW → ASSIGNED
Attachment #528801 - Flags: review?(bzbarsky)
Severity: minor → normal
Priority: -- → P2
Target Milestone: --- → mozilla5
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)
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 on attachment 528801 [details] [diff] [review]
patch

r=me
Attachment #528801 - Flags: review?(bzbarsky) → review+
Attachment #528801 - Flags: approval-mozilla-aurora?
https://hg.mozilla.org/mozilla-central/rev/ebe749bb585b
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: mozilla5 → mozilla6
Attachment #528801 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
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?
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.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: