Closed Bug 1126330 Opened 6 years ago Closed 5 years ago
Reloading page doesn't replay non looping gif making it impossible to see it again
STR: 1) Load this gif: http://i.imgur.com/krYrx02.gif Once you miss the animation you can't see it anymore. Reloading the page in chrome shows the gif again.
Mihai, this will be your second bug.
Assignee: nobody → mvolmer
Comment on attachment 8633280 [details] [diff] [review] Removed the check for non-looping animations This bug only appears on GIFs that have 0ms delay between the frames. If the delay is 10ms or lower it is modified to 100ms. However, this was done only for GIFs that looped more than once. The non-looping GIFs that have 0ms delay were considered to be true-color GIFs. This format is no longer used.
Attachment #8633280 - Flags: review?(seth)
Comment on attachment 8633280 [details] [diff] [review] Removed the check for non-looping animations Review of attachment 8633280 [details] [diff] [review]: ----------------------------------------------------------------- Looks good!
Attachment #8633280 - Flags: review?(seth) → review+
Try looks good as well.
Bug fixing verified and confirmed. Firefox 42b7. Windows 7, 32bit
Platform: Windows 8.1 Pro 64bit Bug is verified and still there in latest beta version 42.0b7 (Build ID: 20151015151621; User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0) However bug is verified and fixed in latest Nightly version 44.0a1 (Build ID: 20151015030233; User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:44.0) Gecko/20100101 Firefox/44.0)
I confirm comment's 10 results. The gif is not replayed when the page is refreshed using Firefox 42 beta 6 under Mac OS X 10.9.5 and Win 7 64-bit. On latest Dev Edition 43.0a2 and Nightly 44.0a1 it works fine.
I can confirm too that the bug is still present in 42.0b7 and 42.0b8. There is something wrong with the target milestone: I think it should be 43. I am wondering how did comment 9 find the bug fixed in 42.b7
Target Milestone reflects when the patch landed on mozilla-central, which was during the Firefox 42 development cycle in this case. https://hg.mozilla.org/releases/mozilla-beta/file/tip/image/FrameAnimator.cpp#l315 confirms that the code change from this patch is present on the branch that Fx42 beta releases are coming from, so it sounds like a question for Seth to maybe answer.
Flags: needinfo?(ryanvm) → needinfo?(seth)
(In reply to Mihai Volmer [:mihaivolmer] from comment #12) > I can confirm too that the bug is still present in 42.0b7 and 42.0b8. > There is something wrong with the target milestone: I think it should be 43. > I am wondering how did comment 9 find the bug fixed in 42.b7 Hi Mihai, I would add more details: When you hard refresh it (CTRL+F5), gif replays. Currently, I am on Firefox 41.0.2 (Hindi-IN, to promote Mozilla India's Hindi Pilot campaign), and I reconfirm that gif replays when you refresh it (CTRL+F5). 41.0.2 (Build ID: 20151014143721; Mozilla/5.0 (Windows NT 10.0; rv:41.0) Gecko/20100101 Firefox/41.0) Thanks
With Nightly 42.0a1, Build ID 20150716030208, so right after the fix landed, the issue doesn't reproduce. So something else might have regressed this. Due to bug 1216883, I can't use mozregression to see if that's the case. Let me know if there's anything else I could help with.
So what we know is: - This patch fixed the bug when it originally landed. - At some point in the 42 cycle, another patch landed that regressed this. - At some point in the 43 cycle, it got fixed again. Things currently work correctly on 43 and 44. I'm afraid that I don't have anything to add beyond that; I'm not sure what we landed in 42 that could've broken this. Looking at the logs for FrameAnimator.cpp and nsGIFDecoder2.cpp, an obvious candidate isn't popping out. If bug 1216883 gets fixed and we can get a regression range, we'd be able to track it down. Otherwise, given that this *is* verified as fixed in 43+, I'm not sure it's worth a manual investigation.
I was able to investigate further and it seems that this was still fixed when 42 Nightly was merged to Aurora, meaning that in the first 42.0a2 Aurora build the issue was fixed and 43 never had the issue. Firefox 42 beta 1 has the issue, so I manually checked some 42.0a2 Aurora builds. Turns out http://ftp-origin-scl3.mozilla.org/pub/firefox/nightly/2015/09/2015-09-10-00-40-36-mozilla-aurora/ regressed this. If I looked correctly, in https://hg.mozilla.org/releases/mozilla-aurora/rev/ada03589e5ea changeset only bug 1181907 landed, and that seems to be back-out already from 42 (or maybe only partially?).
Bug 1181907 can't be it; it was backed out immediately, so that code didn't make it into that build. I don't see any obvious candidate in that build. If I was to guess (and it's only a guess) I'd suspect this commit: https://hg.mozilla.org/releases/mozilla-aurora/rev/2bf9fc66f663 It has happened before that we've had bugs that trigger only with e10s enabled, or only with e10s disabled. That commit disabled e10s on 42.
Aurora 42.0a2 builds 2015-09-09 and 2015-09-10 reproduce the issue only when e10s is disabled. When e10s is enabled, the gif is replayed at refresh.
You need to log in before you can comment on or make changes to this bug.