Cached GIF does not restart from beginning of animation when viewed again
Reported by
murray.r...@gmail.com,
May 15 2018
|
|||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.170 Safari/537.36 Example URL: Steps to reproduce the problem: 1. Have a non-looping GIF in an img tag on a page and observe the GIF until the animation finishes. 2. Reload page (don't hard refresh) and ensure the network request for the GIF gets 304 not modified. 3. Observe that the GIF does not play and retains its state in the animation from step 1. What is the expected behavior? GIF begins playing from start of animation. What went wrong? GIF will retain whatever state in animation it was. Does it occur on multiple sites: Yes Is it a problem with a plugin? No Did this work before? N/A Does this work in other browsers? Yes Chrome version: 66.0.3359.170 Channel: stable OS Version: Ubuntu 16.04 Flash Version:
,
May 16 2018
,
May 16 2018
Thanks for filing the issue! Unable to reproduce the issue on reported chrome version 66.0.3359.170 using Ubuntu 14.04 with the below mentioned steps. 1. Launched chrome 2. Opened a non-looping GIF (https://derpibooru.org/1709636?q=loop) 3. Refreshed the page. We observed the GIF continuing the loop. Attaching the screen cast of the same. @Reporter: Could you please have a look at the screen cast and let us know if we have missed anything. As we are not very clear about later part of point no.2 i.e., "ensure the network request for the GIF gets 304 not modified" It would be highly helpful if elaborated on it. Any further inputs from your end may be helpful.
,
May 16 2018
,
May 16 2018
The screen cast provided is showing a looping GIF. Where I notice the issue in particular is a GIF that does NOT loop. Further examination has revealed that the issue seems to be when the GIF is loaded from memory cache in particular (it shows in the network tab "(from memory cache)" under the "Size" column). Here is an example you can try: Ensure the HTML below is served over HTTP (I can't reproduce visiting the HTML page using file://). I used "python -m SimpleHTTPServer 8000" and visited http://localhost:8000/filename.html to do so. <html lang="en"> <head> <meta charset="UTF-8"> </head> <body> <img src="http://i.imgur.com/oZqny.gif"/> </body> </html> 1. When you first visit the page the animation will play when the GIF loads. Watch the animation until it ends. 2. Reload the page. 3. Ensure the Size column in the network tab for the GIF shows "(from memory cache)" for the GIF. 4. Observe that the GIF does not play its animation from the first frame and instead is on the last frame of the animation. It simply appears to be that whenever GIFs are retrieved from memory cache that they do not restart from their first frame. Instead, they will remain on whatever frame they were on before, and this is regardless of whether you do a page reload (as in my above example) or remove and re-insert the img element into the DOM.
,
May 16 2018
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
May 16 2018
This only occurs if the gif is in an img tag, right?
,
May 16 2018
Seems like it happens outside of img tags as well. Just checked and it happens with:
<div style="background:url('http://i.imgur.com/oZqny.gif'); width: 550px; height: 400px;"></div>
,
May 16 2018
Looks like this is intended behaviour, Firefox and other browsers behave in the same way.
,
May 18 2018
Able to reproduce the issue on reported chrome version 66.0.3359.170 and on latest chrome 68.0.3433.0 using ubuntu 14.04,Windows 10 and Mac 10.13.1. Same behavior is seen on M60(60.0.3112.113) hence considering it as non-regression and marking it as Untriaged. Thanks!
,
May 18 2018
If other browsers do the same thing, then I would say this is WontFix. Maybe try to figure out which spec to file a complaint against?
,
Jun 4 2018
The NextAction date has arrived: 2018-06-04 |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by rbyers@chromium.org
, May 15 2018