Bug 93707 - toggling a inline element's children between display:none/block appends an extra ::after pseudo-element.
Summary: toggling a inline element's children between display:none/block appends an ex...
Status: RESOLVED DUPLICATE of bug 93170
Alias: None
Product: WebKit
Classification: Unclassified
Component: CSS (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified All
: P2 Normal
Assignee: Nobody
URL: http://cssdeck.com/labs/ap7lzpbd/0
Keywords:
Depends on:
Blocks:
 
Reported: 2012-08-10 03:14 PDT by Couto
Modified: 2012-10-01 04:23 PDT (History)
6 users (show)

See Also:


Attachments
WIP (6.91 KB, patch)
2012-09-06 01:56 PDT, Takashi Sakamoto
no flags Details | Formatted Diff | Diff
Patch (5.11 KB, patch)
2012-09-11 17:18 PDT, Takashi Sakamoto
no flags Details | Formatted Diff | Diff
Patch (5.09 KB, patch)
2012-09-27 23:48 PDT, Takashi Sakamoto
inferno: review-
buildbot: commit-queue-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Couto 2012-08-10 03:14:05 PDT
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.
Comment 1 Takashi Sakamoto 2012-09-06 01:56:18 PDT
Created attachment 162452 [details]
WIP
Comment 2 Takashi Sakamoto 2012-09-06 05:33:51 PDT
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
Comment 3 Takashi Sakamoto 2012-09-11 17:18:00 PDT
Created attachment 163485 [details]
Patch
Comment 4 Takashi Sakamoto 2012-09-27 23:48:31 PDT
Created attachment 166152 [details]
Patch
Comment 5 Build Bot 2012-09-28 06:34:45 PDT
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
Comment 6 Abhishek Arya 2012-09-28 21:04:17 PDT
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.
Comment 7 Abhishek Arya 2012-09-29 23:56:58 PDT
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 ***
Comment 8 Takashi Sakamoto 2012-10-01 04:23:18 PDT
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