Closed
Bug 680022
Opened 13 years ago
Closed 3 years ago
Animated gif froze
Categories
(Core :: DOM: Navigation, defect)
Core
DOM: Navigation
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: dr_bugzilla, Unassigned)
References
Details
(Keywords: regression)
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•13 years ago
|
||
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
Blocks: 359608
Status: UNCONFIRMED → NEW
Component: General → Document Navigation
Ever confirmed: true
Keywords: regression
OS: Windows 7 → All
Product: Firefox → Core
QA Contact: general → docshell
Hardware: x86_64 → All
Version: 6 Branch → Trunk
Comment 2•13 years ago
|
||
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•13 years ago
|
||
(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•13 years ago
|
||
>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•13 years ago
|
||
Thanks, the steps in comment 3 show the problem for me. I'll dig into it tomorrow morning.
Comment 6•13 years ago
|
||
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•13 years ago
|
||
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•9 years ago
|
||
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•9 years ago
|
||
[Tracking Requested - why for this release]:
status-firefox37:
--- → ?
status-firefox38:
--- → ?
status-firefox39:
--- → ?
status-firefox40:
--- → ?
tracking-firefox37:
--- → ?
tracking-firefox38:
--- → ?
tracking-firefox39:
--- → ?
tracking-firefox40:
--- → ?
Comment 10•9 years ago
|
||
(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.
status-firefox37:
? → ---
status-firefox38:
? → ---
status-firefox39:
? → ---
status-firefox40:
? → ---
tracking-firefox37:
? → ---
tracking-firefox38:
? → ---
tracking-firefox39:
? → ---
tracking-firefox40:
? → ---
Comment 11•8 years ago
|
||
The link provided throws an error. is there a new link for this bug that can be provided?
Flags: needinfo?(dr_bugzilla)
Comment 12•3 years ago
|
||
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.
Status: NEW → RESOLVED
Closed: 3 years ago
Flags: needinfo?(dr_bugzilla)
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•