New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 843314 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner: ----
Closed: May 2018
Cc:
Components:
EstimatedDays: ----
NextAction: 2018-06-04
OS: Linux , Windows , Mac
Pri: 2
Type: Bug



Sign in to add a comment

Cached GIF does not restart from beginning of animation when viewed again

Reported by murray.r...@gmail.com, May 15 2018

Issue description

UserAgent: 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:
 

Comment 1 by rbyers@chromium.org, May 15 2018

Components: -Blink Blink>Image
Labels: Needs-Triage-M66
Cc: vamshi.kommuri@chromium.org
Labels: Needs-Feedback Triaged-ET
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.
843314.ogv
5.8 MB View Download
NextAction: 2018-06-04
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.

Project Member

Comment 6 by sheriffbot@chromium.org, May 16 2018

Labels: -Needs-Feedback
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
This only occurs if the gif is in an img tag, right?
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>

Looks like this is intended behaviour, Firefox and other browsers behave in the same way.
Cc: phanindra.mandapaka@chromium.org
Labels: M-68 FoundIn-68 Target-68 OS-Mac OS-Windows
Status: Untriaged (was: Unconfirmed)
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!
Status: WontFix (was: Untriaged)
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?
The NextAction date has arrived: 2018-06-04

Sign in to add a comment