273719 - [FIX]CSS generated content cannot be reset with content:normal

Status: RESOLVED FIXED

(Core :: CSS Parsing and Computation, defect, P1)

Description

[Philip Wills]

User-Agent:       Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.8a6) Gecko/20041207

http://terminus.co.uk/tmp/GeneratedTestCase.html contains a pair of divs nested
within an outer div.  Both contain the word 'Static'.  A style assigned using
the :before selector, such that divs within the outer div have the word
"Generated" inserted into display before them.

The second div within the outer one additionally has a class assigned, which is
styled with content: normal, to indicate that no generated content should be
displayed.  I've used some colours as well to highlight the fact that Mozilla is
correctly working out the precedence of the CSS rules.

Opera 7.54 demonstrates the expected behaviour.

Reproducible: Always
Steps to Reproduce:


Actual Results:  
Two lines visible:

Generated Static
Generated Static

Expected Results:  
Two lines visible:

Generated Static
Static

http://www.w3.org/TR/CSS21/generate.html#propdef-content is the pertinent area
of the CSS2.1 recommendation.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Interesting... I thought I'd fixed this in bug 262624.  I missed a case.  :(

Note that if I simply switch the two divs in the DOM such that the one with
content:normal comes first, the rendering becomes correct.  So it's not so much
that content:normal doesn't reset things, but rather that nodes are getting the
wrong style context.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Attachment: Reporter's testcase

Comment 3

[Boris Zbarsky [:bzbarsky]]

Attachment: Patch

I fixed the same bug for counter-reset and counter-increment while I was
here...

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 171014 [details] [diff] [review]
Patch

actually, no this is wrong.  This will mean that when you have a more specific
rule that doesn't specify 'content', the less specific rule will stop working.

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

What should really be happening is explicit handling of Normal and Initial
separate from unspecified.

Comment 6

[Boris Zbarsky [:bzbarsky]]

> actually, no this is wrong.  This will mean that when you have a more specific
> rule that doesn't specify 'content', the less specific rule will stop working.

David, this code is called after all rules have done MapRuleInfoInto(), so the
only way to end up with null here is to have no rules specifying 'content' that
match the node.  Testing with a more specific rule that doesn't specify
'content' shows the less specific rule continuing to work.  I guess in the
latter case aStartStruct won't have a value for 'content' either, though, so
doing the separate handling is ok.  I can do it if you prefer.

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

The problem will only occur if there's a cached struct, which requires a
previous node that matched only the less specific rule.

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

The problem will only occur if there's a cached struct, which requires a
previous node that matched only the less specific rule (in a way that was
cacheable in the rule tree).

Comment 9

[Boris Zbarsky [:bzbarsky]]

Attachment: Take 2

So like this?

Comment 10

[Boris Zbarsky [:bzbarsky]]

Checked in for 1.8b.