Bug 93707 – toggling a inline element's children between display:none/block appends an extra ::after pseudo-element.

• Component: CSS
• Status: RESOLVED DUPLICATE

[Couto]

Overview:
toggling a inline element's children between display:none/block appends an extra ::after pseudo-element.

Steps to Reproduce:
In HTML:
 - Create a <ul> element with some <li> elements as children
In CSS
 - Apply a CSS rule to the <ul> element setting the element to display: inline
 - Set an ::after pseudo-element with the content property to the <ul> element 
 - Set all <li> elements to display: none and then remove the display: none rule (with Javascript)

Actual Results:
Every time the display:none rule is removed from the <li> elements, the <ul> element gets multiple ::after elements

Expected Results:
The <ul> should only have 1 pseudo-element. 

Build Date & Platform:
Google Chrome Version 23.0.1231.0 canary on MacOSX 10.7.4

Additional Builds and Platforms:
Safari Version 6.0 (7536.25) on MacOSX 10.7.4
Webkit (7536.25 537.6+) on MacOSX 10.7.4
Google Chrome Version 22.0.1229.2 dev on MacOSX 10.7.4
Google Chrome Version 21.0.1180.60 m on Windows 7
Chromium 21.0.1180.75-1 on Linux tigon 3.4.7-1-ARCH #1 SMP PREEMPT Sun Jul 29 22:02:56 CEST 2012 x86_64 GNU/Linux

Additional Information:
This bug doesn't happen in non-webkit browsers.

[Takashi Sakamoto]

Created attachment 162452 [details]
WIP

[Takashi Sakamoto]

I'm sorry. This patch is not for fixing this issue. I found the another issue and create the patch.

I will recreate a new patch for this issue.

Best regards,
Takashi Sakamoto

[Takashi Sakamoto]

Created attachment 163485 [details]
Patch

[Takashi Sakamoto]

Created attachment 166152 [details]
Patch

[Build Bot]

Comment on attachment 166152 [details]
Patch

Attachment 166152 [details] did not pass mac-ews (mac):
Output: http://queues.webkit.org/results/14059337

New failing tests:
http/tests/misc/acid3.html

[Abhishek Arya]

this was at one time a security bug and i have run into this. the fix is wrong though. read the comment above.

// Ensure that all of the split inlines pick up the new style. We
163163    // only do this if we're an inline, since we don't want to propagate
164164    // a block's style to the other inlines.
165165    // e.g., <font>foo <h4>goo</h4> moo</font>.  The <font> inlines before
166166    // and after the block share the same style, but the block doesn't
167167    // need to pass its style on to anyone else.

[Abhishek Arya]

This is the same bug as https://bugs.webkit.org/show_bug.cgi?id=93170

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

[Takashi Sakamoto]

Thank you for comments.

(In reply to comment #6)
> this was at one time a security bug and i have run into this. the fix is wrong though. read the comment above.
> 
> // Ensure that all of the split inlines pick up the new style. We
> 163163    // only do this if we're an inline, since we don't want to propagate
> 164164    // a block's style to the other inlines.
> 165165    // e.g., <font>foo <h4>goo</h4> moo</font>.  The <font> inlines before
> 166166    // and after the block share the same style, but the block doesn't
> 167167    // need to pass its style on to anyone else.

I see.
Since this bug is duplicate, I updated a new patch to bug 93107 (taking another way) for fixing the issue.

Best regards,
Takashi Sakamoto