180142 - In a list with position: fixed, switching stylesheets doesn't change list-style-image

Status: RESOLVED FIXED

(Core :: Layout: Positioned, defect)

Description

[Benoit Maisonny]

User-Agent:       Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.2b) Gecko/20021016
Build Identifier: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.2b) Gecko/20021016

This is very similar to Bug 156016, except that if the <li> is in a <ul> which
has position: fixed AND this is set in a separate CSS file than the
list-style-image property, then the bug still appears: the list-style-image
isn't applied.

I made 2 testcases:
1. see URL: the html file uses 2 sets of style sheets, each set is composed of 1
identical file for each set, containing the position: fixed on <ul>; and a
second file which sets list-style-image in one set and list-style-type: none in
the other set.

2. http://www.synclude.com/mozilla/list-style-image2.html : in this case, there
are still 2 sets of style sheets, but each set contains only 1 CSS file, which
defines both the position: fixed and the list-style-* properties.


Reproducible: Always

Steps to Reproduce:
1. Open URL: http://www.synclude.com/mozilla/list-style-image.html
2. Click on the link to togle style sheets (or use the menu View, Use style)
3. Open URL: http://www.synclude.com/mozilla/list-style-image2.html
4. Click on the link to togle style sheets (or use the menu View, Use style)
Actual Results:  
Step 2 sets an image of a green dot on the "special item", not on the "special
item, with ul's position fixed".
Step 4 sets the image on both special items.

Expected Results:  
Step 2: The green dot should appear on both special items.
Step 4: OK


Tested on Moz 1.2b/Linux (2002101612): same result.

Go to http://www.synclude.com/mozilla/ if you want to download each file
separately. They are all named list-item-image*.*, plus the green dot is green.gif.

Possibly related bugs: bug 156016, bug 10820.

Comment 1

[Benoit Maisonny]

Attachment: zip with both testcases

Comment 2

[Hixie (not reading bugmail)]

Please attach the images and the test files to the bug separately, so that the
whole thing can be tested without extracting or downloading any files... thanks

Comment 3

[Benoit Maisonny]

Attachment: First testcase, common CSS

You'll still have to download them from Bugzilla, I suppose, but anyway... here
we go...

Comment 4

[Benoit Maisonny]

Attachment: First testcase, initial CSS

Comment 5

[Benoit Maisonny]

Attachment: First testcase, alternate CSS

Comment 6

[Benoit Maisonny]

Attachment: First testcase, HTML file

Comment 7

[Benoit Maisonny]

Attachment: Second testcase, initial CSS

Comment 8

[Benoit Maisonny]

Attachment: Second testcase, alternate CSS

Comment 9

[Benoit Maisonny]

Attachment: Second testcase, HTML file

Comment 10

[Benoit Maisonny]

Attachment: green bullet image used on 1st and 2nd testcases

Comment 11

[Boris Zbarsky [:bzbarsky]]

If you attach in _reverse_ order (first the images, then the sheets, then the
HTML) and adjust the links to point to the bugzilla attachments, no downloading
is needed... ;)

The problem here is probably the same as in some other bugs we have -- the
positioned list never gets reflown because it's a child of the body and the body
already gets a reflow hint (and we have this assumption that reflowing the body
will properly reflow even its out-of-flow kids). But the containing block is
_not_ the body, so....

Since the bullet frame loads images from Reflow(), and is not getting reflown
here, it does not get loaded.

Comment 12

[Benoit Maisonny]

Thanks for the trick about attachments... Next time, then. Alternatively, just
click on the links I've provided :->

Thanks for the explanation, as well. But: it does work if the style sheets are
merged (2nd testcase).

Comment 13

[Boris Zbarsky [:bzbarsky]]

Yeah, since in the second testcase we dispatch an explicit reflow to the list,
since its position changes (twice -- when we remove the sheet and then apply the
other one).

Comment 14

[Boris Zbarsky [:bzbarsky]]

URLs to usable testcases:

jar:http://bugzilla.mozilla.org/attachment.cgi?id=106222&action=view!/list-style-image.html

jar:http://bugzilla.mozilla.org/attachment.cgi?id=106222&action=view!/list-style-image2.html

Comment 15

[Boris Zbarsky [:bzbarsky]]

OK, I know why this is happening, I think.  The basic issue is that the bullet
frame only tries to load images on Init() and on style change reflow.  But in
this case, it doesn't have the image at Init() time, since the reframe happens
when we set the position, which happens before we've set the bullet.  At the
same time, the reflow triggered by the bullet change never happens, since the
reresolve happens before the initial reflow so the style change reflow is dropped.

The point is, the image shouldn't be loaded from reflow!  Marking dependency on
the bug on that.

Note that comment 11 and comment 13 are wrong.  The reason it works when the
sheets are merged is that the position and the image are set at the same time,
so at Init() we have the right image.

*** This bug has been marked as a duplicate of 236889 ***

Comment 16

[Boris Zbarsky [:bzbarsky]]

Er, wrong textbox....

Comment 17

[Boris Zbarsky [:bzbarsky]]

Attachment: Fix

Comment 18

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 154741 [details] [diff] [review]
Fix

The patch for bug 236889 didn't quite fix it, since we were still looking for
the new image only during a style change reflow...

What this patch does is to move the setting of mImageRequest out of Init() and
Reflow() and into DidSetStyleContext() (since we do want to do this when the
style context is set).	I pretty much copied and pasted the code that used to
be in Reflow().

The remainder of the patch is elimination of the mPresContext member, since
it's unneeded.

Comment 19

[Boris Zbarsky [:bzbarsky]]

Attachment: Updated to nsIPresContext elimination

Comment 20

[Boris Zbarsky [:bzbarsky]]

Fixed.

Comment 21

[Jim Reijers]

*** Bug 296352 has been marked as a duplicate of this bug. ***