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.
Attachment #613209 - Attachment mime type: text/plain → text/html
FYI: A user of this silly little thing I wrote noticed the bug first: http://web.student.tuwien.ac.at/~e0427417/browser-ponies/ponies.html See the bug report to my script: https://bitbucket.org/panzi/browser-ponies/issue/6/animation-stopping-and-ponies-sliding I implemented a workaround by simple replacing the whole image element when the src needs to be changed (if the browser is Gecko based).
Created attachment 613211 [details] example demonstrating animation getting stuck This example automatically changes the src attribute and style 3 times, after which the animation gets stuck. (Tested again in both mentioned setups.)
Attachment #613209 - Attachment is obsolete: true
Attachment #613211 - Attachment mime type: text/plain → text/html
Attachment #613213 - Attachment mime type: application/octet-stream → video/ogg
[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.
Keywords: regression, testcase
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...?
status-firefox11: --- → affected
status-firefox12: --- → affected
status-firefox13: --- → affected
status-firefox14: --- → fixed
tracking-firefox12: --- → ?
tracking-firefox13: --- → ?
tracking-firefox14: --- → ?
Depends on: 721659
I'd be a bit worried about backporting that fix. If this regressed between 10 and 11, what's the range on that? Would be good to know what regressed it...
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.
(In reply to Boris Zbarsky (:bz) from comment #9) > If this regressed between 10 and 11, what's the range on that? Would be > good to know what regressed it... It's a regression from bug 666446. Last good nightly: 2011-11-10 First bad nightly: 2011-11-11 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c60535115ea1&tochange=1374294a6119
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.
tracking-firefox12: ? → +
tracking-firefox13: ? → +
tracking-firefox14: ? → +
(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.
status-firefox13: affected → wontfix
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.