User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:35.0) Gecko/20100101 Firefox/35.0 Build ID: 20150125221831 Steps to reproduce: Unzip this minimal reproducable test case to local drive on windows : http://advance-software.com/misc/local_anim_gif_stall_bug.zip open the html file using ff36b9 *locally* from that drive. Actual results: page displays showing first frame of the animated gif Expected results: the gif should play its animation (it does if you hit refresh or load the page/gif over http.
Component: Untriaged → Layout: Images
OS: Linux → Windows 8.1
Product: Firefox → Core
[Tracking Requested - why for this release]:
via local build Last good: 1d1810ba0ebf First bad: a958224850fb Regressed by: a958224850fb Seth Fowler — Bug 1097432 (Part 1) - Remove imgStatusTracker::Send* methods and clean up.
Timothy, are you going to take that? Matt, can you help on this? FYI, we are going to make a beta 10 before the RC but the go to build is today.
Today is a holiday where I live and I've already made plans so I can't look at this until tomorrow.
(In reply to Alice0775 White from comment #3) > via local build > Last good: 1d1810ba0ebf > First bad: a958224850fb > > Regressed by: a958224850fb Seth Fowler — Bug 1097432 (Part 1) - Remove > imgStatusTracker::Send* methods and clean up. Thank you Alice. This is very helpful.
Assignee: nobody → matt.woodrow
The regressing changeset is http://hg.mozilla.org/mozilla-central/rev/a958224850fb The loop within imgStatusTracker::OnDataAvailable *doesn't* check NotificationsDeferred, unlike all the others within the file. Switching to using the macro added this check, and broke this. This patch just expands the macro out again, and removes the check for NotificationsDeferred.
Attachment #8565137 - Flags: review+
Comment on attachment 8565137 [details] [diff] [review] image-fix Approval Request Comment [Feature/regressing bug #]: Bug 1097432 [User impact if declined]: Animated gifs loaded locally don't animate. [Describe test coverage new/current, TreeHerder]: Tested manually. [Risks and why]: Very low risk, just reverts the one functional change from a patch that was meant to be a cleanup. [String/UUID change made/needed]: None.
Comment on attachment 8565137 [details] [diff] [review] image-fix Guys, you are really impressive! Thanks
I've verified this fix today on Windows 7 x64, using the latest Firefox 37 Aurora (BuildID=20150217004007) which should have this fix (as indicated by its pushlog). I used scenario from comment 0, and while most of the time everything worked fine, on several occasions the GIF did NOT animate (stuck either on the first or the last frame). I could not quite figure out exactly what causes the GIF to not animate when it happens. It seems to reproduce more often if I repeatedly drag the html file in Firefox: 1. Open Aurora with clean profile and drag & drop the local HTML from comment 0 to open it. 2. Drag & drop the HTML in Aurora for the second time. 3. Drag & drop the HTML in Aurora for the third time. In the video from http://www.screencast.com/t/ExCLMK7vqRF you can see how: - step 1 - GIF animates as expected - step 2 - GIF stuck on first frame - step 3 - GIF stuck on last frame As mentioned, this is a scenario where this happens more often, but I've experienced the GIF stuck on first or last frame a few times even when opening the file for the first time with a clean profile. Also note that this also happens in Aurora sometimes when you load http://imgur.com/gallery/rZ4FQoK, so I believe this may actually be a separate issue from this one. If anyone could review this issue and confirm that it's separate from this bug, and not on file, then I can go ahead and file it separately... just let me know. Otherwise it may need fixing ASAP since this fix was already uplifted to Beta 36 and last Beta will happen very soon.
I can confirm reproduced the problem comment#13 on the following Aurora37.0a2(as indicated by its pushlog) https://hg.mozilla.org/releases/mozilla-aurora/rev/997fae1e1f88 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0 ID:20150217004007
It's my understanding (based on comments Seth left in bugs) that he was prioritizing getting his regression fixes uplifted to beta, so that there are several important fixes that could and should be uplifted to aurora but just haven't yet due to lack of time (and using the limited time available to get fixes to beta). So I would say to focus on testing beta and nightly. If neither of those are affected by the bug then it's likely one of the patches that will get uplifted to aurora eventually will fix it.
(In reply to Timothy Nikkel (:tn) from comment #15) > So I would say to focus on testing beta and nightly. If neither of those are > affected by the bug then it's likely one of the patches that will get > uplifted to aurora eventually will fix it. Thank you Timothy! I think you are right about this as I cannot reproduce the issues on Nightly 38 and Beta 36. I didn't get the chance to fully test this today, but from what I managed to do, things look good so far. Tomorrow we'll actually start looking into all the future uplifts to Aurora 37 (that you were mentioning), so I'll return with the final test results then.
I continued testing today on Firefox 36 Beta 10 (BuildID=20150217132925) and the latest Firefox 38 Nightly (BuildID=20150218030228) on Windows 7 x64, but despite trying various scenarios I did not encounter any issues playing the local page with the GIF, or the imgur page with the GIF (confirmed ok also on Mac and Ubuntu). I'm marking this as verified for 38 and 36, and will check 37 after the additional uplifts.
Verified as fixed on Firefox 37 beta 6 under Win 7 64-bit, Ubuntu 14.04 32-bit and Mac OS X 10.9.5.
You need to log in before you can comment on or make changes to this bug.