680022 - Animated gif froze

Status: RESOLVED WORKSFORME

(Core :: DOM: Navigation, defect)

Description

[Dimitri]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20100101 Firefox/6.0
Build ID: 20110811165603

Steps to reproduce:

1) on that page http://smiley.imagup.com/gif-asterix.html
2) right clic on an animated gif => show picture
3) ctrl-wheel up to zoom in
4) press back on history



Actual results:

The whole gifs on page are frozen

Same thing on 2 branches
Firefox 6.0
Firefox aurora 7.0a2 (2011-08-16)

Really not very important

Comment 1

[Alice0775 White]

Regression window(cached m-c hourly)
Works:
http://hg.mozilla.org/mozilla-central/rev/75d2145d1bd3
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b6pre) Gecko/20100907 Firefox/4.0b6pre ID:20100907194131
Fails:
http://hg.mozilla.org/mozilla-central/rev/4bb022d84a31
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b6pre) Gecko/20100907 Firefox/4.0b6pre ID:20100907182227
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=75d2145d1bd3&tochange=4bb022d84a31
Regressed by:
fd33aa85de93	Alon Zakai — Bug 359608 - Animated GIFs are animated even when user navigates to another page.r=bholley,bz;sr=bz;a=blocker

Comment 2

[Boris Zbarsky [:bzbarsky]]

I'm not sure I follow the steps to reproduce.  I load, say http://smiley.imagup.com/asterix/asterix.gif then I zoom in using the menu, then I load http://www.mozilla.org/ and then I go back.  The image are still animating...

Do you see the bug with those steps?  If not, do you see it using the comment 0 steps but using the menu to zoom?

Comment 3

[Alice0775 White]

(In reply to Boris Zbarsky (:bz) from comment #2)
> I'm not sure I follow the steps to reproduce.  I load, say
> http://smiley.imagup.com/asterix/asterix.gif then I zoom in using the menu,
> then I load http://www.mozilla.org/ and then I go back.  The image are still
> animating...
> 
> Do you see the bug with those steps?  If not, do you see it using the
> comment 0 steps but using the menu to zoom?

[STR]
1. Start Firefox with clean profile
2. Open http://smiley.imagup.com/gif-asterix.html
3. Right click on a gif animation
4. Select View Image on contentAreaContext Menu.
5. So an image load on same tab, Zoom in (Ctrl++ Ctrl++) OR Zoom in  using the menu at least twice(Alt>V>Z>I  Alt>V>Z>I)
6. Click Back Button OR Alt+Left arrow key (do not use back space key)

Comment 4

[Alice0775 White]

>Do you see the bug with those steps?
No, I cannot

>If not, do you see it using the comment 0 steps but using the menu to zoom?
Yes, zoom in twice at least,

Comment 5

[Boris Zbarsky [:bzbarsky]]

Thanks, the steps in comment 3 show the problem for me.  I'll dig into it tomorrow morning.

Comment 6

[Boris Zbarsky [:bzbarsky]]

OK, so what's happening here is that the combination of dochell, imagelib, and layout is screwing up the restore.

In particular, the zoom is relevant because it causes nsDocShell::RestoreFromHistory to call SetFullZoom on the document viewer and hence on the prescontext.  That causes a full recomputed of all style data, which in particular picks up a new background style and kicks off the corresponding image load.  That adds the imgRequestProxy to the loadgroup while we're under RestoreFromHistory.

But the _removal_ of that imgRequestProxy is async, so when we get to DocumentViewerImpl::LoadComplete we've already long finished RestoreFromHistory and hence GetRestoringDocument on the docshell returns false at that point, and the OnPageShow for the document is called with aPersisted == 0 even though it's coming out of bfcache.  And that's just bogus, of course.

I'm not quite sure what a good way to fix this is, short of doing those background image loads off a script runner or something so they don't mess with onload or somehow making the onload tracking more clever about presentation restore...

Comment 7

[Boris Zbarsky [:bzbarsky]]

Maybe the right thing to do is to grab the "is restoring" boolean in the docloader when the document request is added, and then propagate it through to the docshell temporarily when actually firing the corresponding onload?

Comment 8

[Peja Stija]

https://cloud.githubusercontent.com/assets/779630/6927159/14c1b692-d809-11e4-900e-2893cb1c10f5.gif

...another example of the fact that Firefox after all those years are not even capable of properly handling a .gif image.

BTW, refreshing that same animated .gif stalls the connection and takes down the whole browser.

Comment 9

[Peja Stija]

[Tracking Requested - why for this release]:

Comment 10

[Alice0775 White]

(In reply to Peja Stija from comment #8)
> https://cloud.githubusercontent.com/assets/779630/6927159/14c1b692-d809-11e4-
> 900e-2893cb1c10f5.gif
> 
> ...another example of the fact that Firefox after all those years are not
> even capable of properly handling a .gif image.
> 
> BTW, refreshing that same animated .gif stalls the connection and takes down
> the whole browser.

I have filed new Bug 1150089. because regression range is different.

Comment 11

[Justin [:JW_SoftvisionQA]]

The link provided throws an error. is there a new link for this bug that can be provided?

Comment 12

[Neha Kochar [:neha]]

The link provided in the original bug report is no longer working. But I tried with the animated gif on a random page I found - https://cynthiafrenette.com/animated-gifs-in-procreate-5/ and followed steps in comment 3 and this is working and no longer an issue.
Closing the bug but please feel free to re-open if you still see the issue.