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

Status: RESOLVED WORKSFORME

(Core :: Networking: Cache, defect)

Description

[Dave Raggett]

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.

Comment 1

[Robert Longson [:longsonr]]

Should be CORE->SVG

Comment 2

[Robert Longson [:longsonr]]

Seems to be a problem in 1.8 and 1.8.1 but is not present with a Trunk build.

Comment 3

[Holger Will]

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

[Andrew Schultz]

Attachment: 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

[Andrew Schultz]

this is fixed on trunk, so a dupe of another bug, or just WFM

Comment 6

[Michael Wu [:mwu]]

Doesn't look like this has anything to do with plugins - moving to Core:SVG.

Comment 7

[Andrew Schultz]

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.

Comment 8

[Michael Wu [:mwu]]

Core:Networking:Cache then, and marking WFM.