Changing <img> src property restarts gif animation
Reported by
qbo...@gmail.com,
Jul 28 2017
|
||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36 Steps to reproduce the problem: (You might need a relatively slow connection) 1. Visit https://jsfiddle.net/s7gjvwvw/1/ 2. Run 3. Click on the image 4. Observe what happens with the old animation before the new one gets loaded What is the expected behavior? Either of the following would make sense to me: A) The old animation should continue to play, while the new file is downloaded, and once it is downloaded it should replace the old one B) As soon as the img.src is changed to a new one, the old animation stops playing, the <img> starts to look like there is no image available, until the new gif is available and then the new animation starts to play What went wrong? As soon as the img.src gets replaced, the old animation rewinds to beginning abruptly and then continues to play in a loop until the new one is loaded. The strange thing here is this rewinding. Did this work before? N/A Does this work in other browsers? Yes Chrome version: 59.0.3071.115 Channel: n/a OS Version: 10.0 Flash Version: Originally I found this behaviour when going through Elm tutorial: http://elm-lang.org/examples/http and was about to blame it on Elm reconciliation algorithm, but as you can see it's actually a problem with Chrome.
,
Aug 3 2017
Tested on Chrome Stable #60.0.3112.90, Canary #62.0.3174.2 on Windows 7, Mac 10.12.6, Ubuntu 14.04 and able to reproduce the issue. This is a non-regression issue and able to reproduce from M-45 #45.0.2454.85. Marking it as untriaged so that issue gets addressed. Behavior in FireFox seems to be similar to the point mentioned in Point A in expected behavior. Thanks.
,
Aug 3 2017
,
Sep 8 2017
,
Sep 11 2017
,
Sep 11 2017
> Does this work in other browsers? Yes Hmm, not sure about this, I see the reported behavior in Safari, Version 10.1.2 (12603.3.8) too.
,
Sep 11 2017
#6 - that is not surprising, as it is probably a WebKit originated issue. Internet Explorer 11 and Edge 15 pause the image until the new one is rendered. Firefox 55 continues as usual until the new one is rendered. Safari behaves the same as Chrome (immediately restarts). This fiddle has a bit more delay for loading before the server responds with the next image, easier to see the results using BrowserStack - https://jsfiddle.net/dtayyLfb/
,
Sep 11 2017
,
Sep 11 2017
,
Sep 13 2017
Testing on M60 just now. It seems to restart the existing animation before moving to the next. So for example, if we are on frame 20 and you change the src, it appears to immediately jump to frame 1 again. Unfortunately, I can't quite tell if it pauses or if it continues to frame 2. I can try again on a slower network. Or better, I'll take a trace. If nothing else, it would probably be better to at least not jump back to frame 1.
,
Sep 13 2017
There is some logic here for resetting the animation here (https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/graphics/BitmapImage.cpp?l=568). You can check if a src change is inadvertently triggering this.
,
Sep 13 2017
The reset is likely the one at the end of ImageLoader::DoUpdateFromElement (triggered by 'src' update via microtask.) Specwise, the relevant section is https://html.spec.whatwg.org/multipage/images.html#updating-the-image-data and specifically the term "restart the animation" (https://html.spec.whatwg.org/multipage/rendering.html#restart-the-animation) and the associated flag (which is set by a 'src' mutation.) IIRC, the animation should essentially only be reset/restarted when the same image resource is set again. (Code mentioned above appears to do it always.)
,
Oct 14 2017
Draft CL to not restarting animation in the code mentioned in Comment #12: https://chromium-review.googlesource.com/c/chromium/src/+/720241 This stops rewinding mentioned in #0. (The implementation is not so clean though...)
,
Oct 15
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 15
|
||||||||||
►
Sign in to add a comment |
||||||||||
Comment 1 by ranjitkan@chromium.org
, Aug 2 2017