57226 - [FIX][RR]Changing attributes does not reframe :before/:after generated content [GC]

Status: VERIFIED FIXED

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

Description

[Hixie (not reading bugmail)]

STEPS TO REPRODUCE
   Change the content of an element's attribute, thus causing style contexts
   to be reresolved and thus causing :before or :after 'content' to change.

ACTUAL RESULTS
   The contents don't change.

EXPECTED RESULTS
   Well duh.

See attachement for a simple case. During loading, the attribute of one of the
elements is changed. If the test passes, the generated content should be changed
from 'FAILED' to 'PASSED'.

Comment 1

[Hixie (not reading bugmail)]

Attachment: Simple and self explanatory testcase. Output should say "Result: PASSED".

Comment 2

[Pierre Saslawsky]

Interesting problem with an interesting workaround: if you attempt to change the 
after-content, it doesn't work. However, you can remove the after-content (with a 
before-content for instance) and once it is removed, you can add the after-
content you wanted.  A bit confusing eh?   Look at the attached testcase and it 
will be all clear.

Comment 3

[Pierre Saslawsky]

Attachment: testcase with workaround

Comment 4

[Pierre Saslawsky]

I forgot to add that:
- the style is indeed re-resolved, it even applies to the after-content, the only 
problem is that the after-content itself doesn't change.
- the after-content doesn't appear in when dumping the content in Viewer.

Comment 5

[Hixie (not reading bugmail)]

See also http://www.hixie.ch/tests/adhoc/dom/css/rematching/004.xml

Comment 6

[Kai Lahmann (is there, where MNG is)]

for me :before got added

http://mozilla.linuxfaqs.de/

..set style to "false frame" - the the red ">" before the links IS a :before,
and gets added. The external links should get an :after{content:" (extern)";},
but THAT doesn't work

Comment 7

[Jesse Ruderman]

What I'm seeing is bug 126072, :before and :after psuedo classes are not
rendered when using alternate style sheets.

Comment 8

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

I'm going to mark this bug as *depending on* bug 126072 because this bug may
also have issues with AttributeAffectsStyle (and I've been wondering whether
AttributeAffectsStyle should have worked a little more like
HasStateDependentStyle...).

Comment 9

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

Assigning pierre's remaining Style System-related bugs to myself.

Comment 10

[Boris Zbarsky [:bzbarsky]]

Attachment: This testcase is basically the same bug.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Attachment: Proposed fix

Since the generated content is generated during frame construction, any change
to generated content requires creating the new frames....

Comment 12

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

Comment on attachment 88554 [details] [diff] [review]
Proposed fix

r=dbaron.  Seems like the right fix.  Perhaps the "XXX" could go?

Comment 13

[Boris Zbarsky [:bzbarsky]]

Yeah, true.  I'll remove the XXX before checking in.

Comment 14

[kinmoz]

Comment on attachment 88554 [details] [diff] [review]
Proposed fix

sr=[e-mail]

Comment 15

[Boris Zbarsky [:bzbarsky]]

fixed on trunk

Comment 16

[Madhur Bhatia]

all testcases working as desired .. tested on win2k and linux 7.2 --
2002-11-05trunk builds