[SELECTORS-DYNAMIC] we don't restyle for + combinator and content tree changes

RESOLVED FIXED in mozilla1.9beta4

Status

()

Core
CSS Parsing and Computation
RESOLVED FIXED
14 years ago
10 years ago

People

(Reporter: dbaron, Assigned: dbaron)

Tracking

({css3, testcase})

Trunk
mozilla1.9beta4
css3, testcase
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 2 obsolete attachments)

(Assignee)

Description

14 years ago
Our handling of content tree changes (removeChild, insertChild, appendChild,
replaceChild) doesn't cause the necessary restyling to handle the + combinator
in CSS selectors.

This is spun off of bug 15608 and is related to bug 73586 and bug 98997.  I'll
attach a testcase sometime...
(Assignee)

Comment 1

14 years ago
Bug 73586, bug 98997, and bug 229915 would be fixed by what I described in step
3 of bug 15608 comment 28:

  When adding/removing content, just reresolve style on the parent (to handle
  empty, +, and all the new CSS3 variants).  (Perhaps there are good ways to
  optimize this, but it might just not be that bad.)
Created attachment 139246 [details]
inserting element div with insertBefore between a and span with style a+span{background-color:green}
(Assignee)

Comment 3

14 years ago
Created attachment 139252 [details]
testcase
Attachment #139246 - Attachment is obsolete: true
(Assignee)

Comment 4

14 years ago
Created attachment 139253 [details]
testcase
Attachment #139252 - Attachment is obsolete: true
(Assignee)

Comment 5

14 years ago
It's worth testing ~ as well -- some issues are similar, but some are a bit
different.

Updated

14 years ago
Keywords: css3, testcase
Summary: [SELECTORS-DYNAMIC] we don't restyle for + combinator and content tree changes → we don't restyle for + combinator and content tree changes
(Assignee)

Updated

14 years ago
Summary: we don't restyle for + combinator and content tree changes → [SELECTORS-DYNAMIC] we don't restyle for + combinator and content tree changes

Updated

11 years ago
Blocks: 343652
(Assignee)

Comment 6

11 years ago
*** Bug 343652 has been marked as a duplicate of this bug. ***
No longer blocks: 343652

Comment 7

11 years ago
*** Bug 344990 has been marked as a duplicate of this bug. ***

Updated

11 years ago
Blocks: 371061
(Assignee)

Updated

10 years ago
QA Contact: ian → style-system

Comment 8

10 years ago
I just ran into this bug. I have:

h1 + p { text-indent: 0 }
p { text-indent: 2em }

The bug is triggered if I remove a paragraph directly following a header, as the following paragraph that gets moved up is stuck with the old indentation.

Is there a simple workaround for this bug?
(Assignee)

Updated

10 years ago
Depends on: 401291

Comment 9

10 years ago
Hit upon this in bug 393718 / attachment 295517 [details] [diff] [review].

Comment 10

10 years ago
Created attachment 298239 [details]
Additional testcase

Additional testcase
(Assignee)

Comment 11

10 years ago
Fix by checkin of bug 401291 to trunk, 2008-02-18 22:17 -0800.

I included tests for this bug (based on attachment 139253 [details]) in that landing.  However, I think more tests are needed, as none of the tests currently in the tree test any cases where :empty and :-moz-only-whitespace differ, and those cases need to be exercised a good bit.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9beta4
(Assignee)

Updated

10 years ago
Blocks: 418463
You need to log in before you can comment on or make changes to this bug.