WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED CONFIGURATION CHANGED
33479
Replacing hidden element causes first-child selector to behave weirdly
https://bugs.webkit.org/show_bug.cgi?id=33479
Summary
Replacing hidden element causes first-child selector to behave weirdly
NovakP
Reported
2010-01-11 11:10:05 PST
Hi, I found bug in first-child rendering: In provided testcase (see URL), clicking on link replaces hidden TD element #first using jQuery 1.4 method replaceWith() with another element. However, WebKit fails to render it correctly, because it hides not only replaced :first-child (as it should), but also second TD child of table row. And when I looked into Web Inspector, it says that second TD child is visible. When I replaced :first-child by :first-of-type or even :nth-child(1) (in the testcase these are equal), everything works as expected. This issue occurs in stable Webkit browsers versions and also in nightly builds of Webkit. I reported this issue to jQuery team, but they said it's not bug in their library.
Attachments
[REDUCTION] Simple HTML/CSS/JS Showing The Problem
(1.23 KB, text/html)
2010-03-13 22:03 PST
,
Joseph Pecoraro
no flags
Details
View All
Add attachment
proposed patch, testcase, etc.
Joseph Pecoraro
Comment 1
2010-03-13 22:03:28 PST
Created
attachment 50668
[details]
[REDUCTION] Simple HTML/CSS/JS Showing The Problem Attached a simpler reduction. Whenever a new first child element is inserted into a :first-child position where a :first-child selector has display:none, then any existing element affected by the :first-child selector is not updated correctly. Notes: This is not specific to <td>s. The exact same problem happens with :last-child and inserting the new element as the last child (appendChild instead of insertBefore). I did not test :only-child.
Ahmad Saleem
Comment 2
2022-07-23 05:23:33 PDT
I am unable to reproduce this bug using attached test case in Safari 15.6 on macOS 12.5 and it matches with other browsers (Chrome Canary 106 and Firefox Nightly 104). As mentioned in expected result, it shows t2 and then inserting new bring back 't1' and then it brings x, x , x and it matches with other browsers. I think it might be fixed along the way and can be considered "RESOLVED CONFIGURATION CHANGED". Thanks!
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug