Animated GIFs sometimes freeze when going back or forward with bfcache

RESOLVED WORKSFORME

Status

()

Core
Document Navigation
--
minor
RESOLVED WORKSFORME
13 years ago
10 years ago

People

(Reporter: Steve Chapel, Unassigned)

Tracking

Trunk
x86
Windows XP
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

13 years ago
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.

Comment 1

13 years ago
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.
(Reporter)

Comment 2

13 years ago
(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.

Comment 3

13 years ago
Created attachment 182931 [details]
animated gif for testing

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. ***

Comment 6

13 years ago
(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

Comment 7

13 years ago
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+

Comment 8

13 years ago
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.

Comment 9

13 years ago
I definitely agree. Most webpages portals etc have banners

Comment 10

13 years ago
(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
Last Resolved: 13 years ago
Resolution: --- → WORKSFORME

Updated

10 years ago
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.