Comment on attachment 613209[details]
example demonstrating animation getting stuck
Click back and forth between the two buttons in the attached file. After the second or third click it gets stuck for me.
The buttons change the src attribute and the width and height styles. I used data:-urls in the example just so everything is included in the html file. The same thing occurs when it's a normal url to a gif on a web server.

(In reply to panzi from comment #0)
> Steps to reproduce:
>
> I wrote a JavaScript animation that changes the src and style (width and
> height) attributes of GIF images. The new src is another animated GIF.
Could you provide actual steps that someone can follow to (hopefully) trigger the bug? The more detailed the better. It's OK if the steps don't trigger the bug 100% of the time -- I just want to be sure I & others are following roughly the same procedure as you.
(As noted in bug 691792 comment 22, I haven't yet been able to reproduce, from madly clicking back and forth between the buttons, using Nightly as well as the Ubuntu-provided Firefox 11 package on Linux x86.)
Also -- if it's possible to construct a testcase that automatically triggers the bug (no mysterious clicking required), that would be amazing.
e.g. it looks like you could have <html onload="go()"> where "go()" calls showFly / showDash a bunch of times with setTimeouts. (enough to trigger the bug)

[Oops, sorry -- when I thought I was using Ubuntu's Firefox 11 package, I was in fact still using Nightly. Sorry for my mistake on that. In any case, thanks for the automatic testcase -- it's much easier to test with!]
I can reproduce with both attached testcases, using...
- Firefox 11 (from Ubuntu)
- current Firefox Beta (12) and Aurora (13), just-downloaded
However, it's fixed in Nightly.

I tracked down the fix range on trunk.
Last bad nightly: 2012-03-20
First good nightly: 2012-03-21
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b972b89518c3&tochange=4bdae514b9be
This changeset looks the most promising/related, from that range:
0f6ef3a02450 Boris Zbarsky — Bug 721659. Update the width/height of an image synchronously when src is set to something that was preloaded. r=bholley
I also verified that Firefox 10 is unaffected:
Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20100101 Firefox/10.0.2
So this is a new regression in Firefox 11.
As a result, it looks like this isn't an exact duplicate of bug 721659, since (per bug 721659 comment 4) that bug affects builds at least as old as Firefox 9. This just is a bug that happens to be fixed by that bug's patch.
I wonder if that means we might want to backport that bug's patch, to fix this regression...?

Or to put it another way, it sounds like there's some sort of race here that leads to bad behavior in some cases. The fix for bug 721659 changes the timing, so might affect who wins the race in a given testcase, but there still seems to be a fundamental underlying problem.

Unless there is a near-zero risk fix or backout for this bug, the user pain here does not appear significant enough to introduce unnecessary risk for FF12. Tomorrow (4/10) is the latest we'd be willing to take a fix for that release.

(In reply to Alex Keybl [:akeybl] from comment #12)
> Unless there is a near-zero risk fix or backout for this bug
Per comment 9, the patch that fixed this on trunk has nonzero risk, and a backout (of bug 666446) would be huge & have nonzero risk as well.
> the user pain
> here does not appear significant enough to introduce unnecessary risk for
> FF12.
Agreed.

I suspect this bug is worth mentioning in the "known issues" of Firefox 12 release notes, since it's a regression (w.r.t. Firefox 10).
Adding "relnote" keyword (hopefully that's the right thing to do).

(In reply to Daniel Holbert [:dholbert] from comment #13)
> (In reply to Alex Keybl [:akeybl] from comment #12)
> > Unless there is a near-zero risk fix or backout for this bug
>
> Per comment 9, the patch that fixed this on trunk has nonzero risk, and a
> backout (of bug 666446) would be huge & have nonzero risk as well.
Sounds like the same logic applies to FF13 in that case. We'll wait for FF14 to see this fixed.

Firefox 14 (which includes the patch for bug 721659) has now been released, so this bug is now fixed in all releases. (Note that ESR 10.* should also be unaffected by this bug, as this was a regression in Firefox 11 (per the middle of comment 8 and comment 11))
So I don't think there's any reason to leave this bug open at this point.
Resolving as FIXED by bug 721659. (Note that it's not an exact dupe, per the end of comment 8)

Status: NEW → RESOLVED

Last Resolved: 7 years ago

Resolution: --- → FIXED

Target Milestone: --- → mozilla14

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