Reload picks wrong SVG image from cache when correct image is hidden via CSS

RESOLVED WORKSFORME

Status

()

Core
Networking: Cache
RESOLVED WORKSFORME
12 years ago
11 years ago

People

(Reporter: Dave Raggett, Unassigned)

Tracking

({testcase})

1.8 Branch
x86
Linux
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050702
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050702

If an  SVG image is hidden by a script that sets the visibility of a parent element (e.g. a div) to hidden and display to none, and there is another SVG image on the page, then when reloading the page, the browser will show the wrong SVG image (the one that was visible when then page was reloaded).

Reproducible: Always

Steps to Reproduce:
1.Load the test URL in a build with support for SVG enabled
2.click on the text as it instructs you to do
3.the W3C logo is replaced by three colored circles
4.Reload the page - it should then show the W3C logo
but it doesn't and instead shows the 3 colored circles.
5.If the W3C logo appears after step 4, repeat steps 2-4
6.Once it goes wrong it remains that way until the browser
is restarted. You may have to repeat steps 2-4 several
times for the wrong image to appear.

Actual Results:  
The browser displays the wrong SVG image

Expected Results:  
It should display the correct image, i.e. the one shown when the page was first loaded in that session (i.e. since the browser was last started).

I was able to reproduce this on the latest nightly build of Firefox, and also on Galeon 2.01 (a gnome browser based upon Mozilla). The latest nightly build of Mozilla itself didn't include support for SVG. I note that Firefox appears to
delay loading SVG images from the server until the image is made visible through the CSS display and visibility properties. By contrast Galeoon appears to load all SVG images when the page is first loaded regardless of the CSS display/visibility properties.

This bug is an issue for web applications that use scripting to dynamically hide and show different parts of the markup, e.g. for slide presentations.
Should be CORE->SVG
Component: General → SVG
Product: Mozilla Application Suite → Core
Version: unspecified → 1.8 Branch
Seems to be a problem in 1.8 and 1.8.1 but is not present with a Trunk build.

Comment 3

12 years ago
after seeing the bug, when i click in the address and press enter the page is reloaded correctly, no need to restart the browser.

Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1b1) Gecko/20060710 Firefox/2.0b1

Comment 4

12 years ago
Created attachment 232393 [details]
testcase

With a 1.8 branch build,

click in the window
=> image changes
reload
=> image doesn't change

the same happens with other OBJECTs.

A debug build asserts whenever anything happens (load, click, reload):

###!!! ASSERTION: bad reflow state: 'aReflowState.frame == aKidFrame', file /build/andrew/seamonkey11/mozilla/layout/generic/nsContainerFrame.cpp, line 879

when clicking, I also get

###!!! ASSERTION: Adding child where we already have a child?  This will likely misbehave: 'Error', file /build/andrew/seamonkey11/mozilla/xpfe/components/shistory/src/nsSHEntry.cpp, line 520

A trunk build does not assert and also shows the objects with the correct width.

Comment 5

12 years ago
this is fixed on trunk, so a dupe of another bug, or just WFM
Assignee: general → nobody
Status: UNCONFIRMED → NEW
Component: SVG → Plug-ins
Ever confirmed: true
Keywords: testcase
QA Contact: general → plugins

Comment 6

11 years ago
Doesn't look like this has anything to do with plugins - moving to Core:SVG.
Component: Plug-ins → SVG
QA Contact: plugins → general

Comment 7

11 years ago
this may not be plugins, but it's certianly not SVG.
see comment 4 and (in particular) the testcase

based on the lack of interest, this should probably just be WFM'd.
Component: SVG → Plug-ins
QA Contact: general → plugins

Comment 8

11 years ago
Core:Networking:Cache then, and marking WFM.
Component: Plug-ins → Networking: Cache
QA Contact: plugins → networking.cache

Updated

11 years ago
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.