gif playback restarts once a JS-inserted image is fully loaded

RESOLVED FIXED in mozilla16



7 years ago
7 years ago


(Reporter: blendmaster, Assigned: rclick)


13 Branch
Windows 7
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(Not tracked)




(1 attachment, 1 obsolete attachment)



7 years ago
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20100101 Firefox/13.0
Build ID: 20120509070325

Steps to reproduce:

Load a page containing an animated .gif that is dynamically inserted into the page using `document.createElement('img')` and appending the Element to the body.

Actual results:

The gif animation will restart from the beginning as soon as it is fully loaded (fires the `onload` callback), even if the playback had advanced with the downloaded-part of the image. This resetting of playback often happens in the middle of the image, which is annoying.

.gifs loaded in regular image tags do not display this behavior.

This effect can be seen at:

Expected results:

Once a dynamically inserted .gif becomes fully loaded, it should keep playing from the currently displayed frame.
Component: Untriaged → ImageLib
Product: Firefox → Core
QA Contact: untriaged → imagelib
I'm not seeing the problem with a Mac nightly, if I understand the problem description correctly....

Comment 2

7 years ago
I took a video of the effect:

The second and third videos have an onload handler that changes the opacity of the image back to 1, so the image appears faded until it fully loads. While the gif in the <img> tag loads fully, playback continues. In the dynamically loaded image, playback restarts from the beginning. If this didn't happen, the playback of all three images would be nearly in sync even after all three were loaded.

Another interesting effect is that when the dynamically loaded image's src is the same as the <img> tags, then the animation reset occurs on all the images:

I can additionally reproduce this bug on Firefox 11, on the same system (Windows 7 x64).
Ah, ok.  I can get this to happen, sometimes.  Weird....

Comment 4

7 years ago
The effect is best seen with a clear cache, so the download time and delta between playback is significant. I always reload my example pages from the server with Ctrl+Shift+R.
Ctrl+Shift+R might affect behavior here: it marks the images as uncacheable entirely (including in the image cache, iirc), so if anything requires a possible reload of the image it will be refetched from the server.

The only sane way to test the behavior here is with a clean profile for each test....

Comment 6

7 years ago
I wrote a really simple userscript that also displays this bug: (click on 'raw' to install with GM)

With the userscript installed using Greasemonkey or Scriptish, browse to and hover the mouse over one of the thumbnails. The full .gif will be dynamically inserted into the document, with the same opacity change onload. You can see the playback restart effect on most of the images.

You can use the same userscript in Chrom{e|ium}, and the playback does not restart when the image loads.

(In reply to Boris Zbarsky (:bz) from comment #5)
> Ctrl+Shift+R might affect behavior here: it marks the images as uncacheable
> entirely (including in the image cache, iirc), so if anything requires a
> possible reload of the image it will be refetched from the server.
> The only sane way to test the behavior here is with a clean profile for each
> test....

I don't think Ctrl+Shift+R effects the behavior beyond making the time between initially displaying the image and the onload event long enough to observe the effect. The effect still occurs even with cached images (watch for the little flash of reduced opacity in one of the tests), but it's less annoying and noticeable.

Comment 7

7 years ago
I'm seeing this bug as described in Firefox 12.0 and Nightly 15.0a1 (2012-05-27) on Intel Mac OSX 10.6.8, and also in a difference scenario: 

A pre-release version of my add-on "Thumbail Zoom Plus" shows a pop-up image in an <html:img> element.  The element itself is statically defined in chrome's overlay.xul but its src URL is set dynamically from javascript.  The gif starts playing before it is completely loaded as expected, but restarts playing from the beginning as soon as loading completes.  So the user sees the beginning of the animation play twice, which is bad.

I could work around it by not displaying the image until I get onload, but that would make the user wait longer before it starts playing.

Comment 8

7 years ago
The problem happens even if the <img> tag is directly in the html rather than JS-inserted, but the src is set dynamicall from JS.  eg:

<img id="dynamic-img" style="">                    
document.addEventListener( 'DOMContentLoaded', function () {
        var img = document.getElementById('dynamic-img');                              
        img.src = '';                  = 0.5;                                                     
        img.addEventListener( 'load', function () { 
                        = '';

Comment 9

7 years ago
Created attachment 631897 [details] [diff] [review]

So, it turns out that we're waiting until OnStopDecode to reset the animation after the .src changes, when it should really be happening sooner than that.

This patch changes that so the animation is reset when we add a new current request, or when a pending request becomes the current request.
Assignee: nobody → rclickenbrock
Ever confirmed: true
Attachment #631897 - Flags: review?(bzbarsky)
Comment on attachment 631897 [details] [diff] [review]

Bobby, feel free to steal this from Boris.
Attachment #631897 - Flags: review?(bobbyholley+bmo)
Comment on attachment 631897 [details] [diff] [review]

Attachment #631897 - Flags: review?(bzbarsky) → review+

Comment 12

7 years ago
Created attachment 632810 [details] [diff] [review]
patch for check-in

Updated commit message for check-in. Carrying forward r=bz.
Attachment #631897 - Attachment is obsolete: true
Attachment #631897 - Flags: review?(bobbyholley+bmo)
Attachment #632810 - Flags: review+


7 years ago
Keywords: checkin-needed

Should this have a test?
Flags: in-testsuite?
Keywords: checkin-needed
Target Milestone: --- → mozilla16
Last Resolved: 7 years ago
Resolution: --- → FIXED

Comment 15

7 years ago
This probably should have a test, but I'm having trouble figuring out a way to test it.

Joe, do you have any ideas? I looked into having an image with a non-looping animation and a listener that implements imgIDecoderObserver/imgIContainerObserver which tracks how many times frameChanged is called, but that won't work because frameChanged is noscript...
You could use imgIContainerDebug, which has an attribute, framesNotified, you can look at.
You need to log in before you can comment on or make changes to this bug.