Closed Bug 293234 Opened 15 years ago Closed 15 years ago

Animated GIFs sometimes freeze when going back or forward with bfcache

Categories

(Core :: Document Navigation, defect, minor)

x86
Windows XP
defect
Not set
minor

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: schapel, Unassigned)

References

()

Details

Attachments

(1 file)

Reproducable: Always

Steps to Reproduce:
1. Go to about:config and set browser.sessionhistory.max_viewers to 1
2. Restart the browser
3. Go to http://forums.mozillazine.org/
4. Click on "View posts since last visit" link near the top of the page
5. Right-click one of the animated page images near the left side of the window
and select View Image
6. Click the Back button twice
7. Click the Forward button twice

Expected Results: The animated page GIF is displayed and animates
Actual Results: The animated page GIF is displayed but is frozen

This problem also occurs with all pages that contain animated GIFs, not just
when viewing GIFs in isolation. Reloading the page will restart the GIFs. I'm
using Mozilla trunk build 2005050605 on Windows XP SP2.
Your bug summary says "sometimes", but it always happens. You click a link on a
page with an animated GIF, press Back, and the GIF doesn't animate anymore. This
is with "blazingly fast back/forward" enabled, of course.
(In reply to comment #1)
> Your bug summary says "sometimes", but it always happens.

Actually, I wasn't able to come up with a 100% reliable way of reproducing the
problem. Oops, comment #0 should read "Reproducable: Sometimes". If you have a
foolproof way of making the problem occur, please post the steps.
As it was hard to find, I´ll attach it: the animated gif you are searching for
at Mozillazine forums. The steps to repeat were also missing to tell you need
to login.
*** Bug 293797 has been marked as a duplicate of this bug. ***
*** Bug 294166 has been marked as a duplicate of this bug. ***
(In reply to comment #2)
> If you have a foolproof way of making the problem occur, please post the steps.

I'm the reporter of #294166, the steps I posted there always show this behavior
2 additional testcases:

http://home.arcor.de/jonha/testcase/index.htm
http://home.arcor.de/jonha/testcase/second.htm

Reproducable: Always
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b2) Gecko/20050517 Firefox/1.0+
I really dont want to bugspam, but can we get this priority set above "minor"?
1.1 couldn't go live to the masses with a bug like this - a lot of forumers will
find their experiences somewhat "broken" and that might have an impact on
recruitment, if you will.
I definitely agree. Most webpages portals etc have banners
(In reply to comment #8)
> I really dont want to bugspam, but can we get this priority set above "minor"?
> 1.1 couldn't go live to the masses with a bug like this - a lot of forumers will
> find their experiences somewhat "broken" and that might have an impact on
> recruitment, if you will.

bfcache is not (and certainly will not be) activated by default, so this bug
doesn't have to be of higher priority. I don't think that bfcache is going to be
activated until all annoying bugs caused by it (like this one) are fixed.
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050616
Firefox/1.0+ ID:2005061606
Is this bug still present? Maybe fixed by bug 292971?
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050616
Firefox/1.0+ ID:2005061607

WFM
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
Component: History: Session → Document Navigation
QA Contact: history.session → docshell
You need to log in before you can comment on or make changes to this bug.