Last Comment Bug 73586 - matching of :first-child, :only-child, and :last-child not dynamically updated [SELECTORS-DYNAMIC]
: matching of :first-child, :only-child, and :last-child not dynamically update...
Status: RESOLVED FIXED
[Hixie-P3] important DOM1 bug (py8ieh...
: css2, css3, dom2, testcase
Product: Core
Classification: Components
Component: CSS Parsing and Computation (show other bugs)
: Trunk
: All All
: P1 normal with 15 votes (vote)
: mozilla1.9beta4
Assigned To: David Baron :dbaron: ⌚️UTC-10
:
: Jet Villegas (:jet)
Mentors:
: 192151 254598 303775 357811 414043 (view as bug list)
Depends on: 46916 401291
Blocks: 303775 357811 373298 acid3
  Show dependency treegraph
 
Reported: 2001-03-27 04:10 PST by Daniel Glazman (:glazou)
Modified: 2010-03-05 08:59 PST (History)
48 users (show)
dbaron: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
DHTML test case (1.24 KB, text/html)
2001-03-27 04:12 PST, Daniel Glazman (:glazou)
no flags Details
Clearer first-child testcase (767 bytes, text/html)
2004-05-29 11:59 PDT, Boris Zbarsky [:bz] (still a bit busy)
no flags Details
Clearer last-child testcase (732 bytes, text/html)
2004-05-29 12:03 PDT, Boris Zbarsky [:bz] (still a bit busy)
no flags Details

Description Daniel Glazman (:glazou) 2001-03-27 04:10:33 PST
the attached testcase offers two links. Clicking on the first one will insert a
paragraph as first child of body. That paragraph should get the style from

  p:first-child { border : thick green solid }

A second link appends a paragraph to the children of body and the following rule
applies to it :

  p:last-child { border : thick red solid }

*** NOTE : this last rule only running if bug 42916 checked in ***

Inserting new paragraphs at the beginning or at the end of body should make the
paragraph who had the green or red border loose that border in favor of the
newly created one. It does no work.
Comment 1 Daniel Glazman (:glazou) 2001-03-27 04:12:06 PST
Created attachment 28902 [details]
DHTML test case
Comment 2 James Lariviere 2001-03-28 10:39:11 PST
I think dan means bug 46916 (last-child) not bug 42916?
Comment 3 Daniel Glazman (:glazou) 2001-03-30 06:42:10 PST
yes, 46916 ; sorry.
Comment 4 David Baron :dbaron: ⌚️UTC-10 2001-04-02 21:00:53 PDT
I don't see how this has anything to do with reflow.  Isn't it just that we
don't do enough dynamic re-styling when the content model is changed?  As we
add new selectors, we're probably going to run into more problems like this
unless we do more re-resolution.  (I wrote a comment to myself in
nsCSSFrameConstructor::ContentInserted that it may not re-resolve enough for
the CSS2 '+' combinator, although I never had a chance to test that.  Would
that be the right place to do it?  How much of a performance cost would such
changes be?  What optimizations could we make to avoid such a cost (particularly
for :subject)?)
Comment 5 Jonas Sicking (:sicking) No longer reading bugmail consistently 2001-09-16 19:13:58 PDT
related to bug 98997
Comment 6 Hixie (not reading bugmail) 2001-11-20 16:28:26 PST
The "+" issue is bug 110972.
Comment 7 Kevin McCluskey (gone) 2002-02-22 09:54:41 PST
Bulk moving Moz1.2 bugs to future-P2. I will pull from this list when scheduling
work post Mozilla1.0
Comment 8 Madhur Bhatia 2002-05-17 14:30:36 PDT
cc'ing myself
Comment 9 David Baron :dbaron: ⌚️UTC-10 2002-06-19 21:20:11 PDT
Assigning pierre's remaining Style System-related bugs to myself.
Comment 10 Boris Zbarsky [:bz] (still a bit busy) 2003-02-06 23:20:20 PST
*** Bug 192151 has been marked as a duplicate of this bug. ***
Comment 11 David Baron :dbaron: ⌚️UTC-10 2004-01-02 11:17:47 PST
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.)
Comment 12 David Baron :dbaron: ⌚️UTC-10 2004-04-05 22:09:24 PDT
The problem is that that would be O(N^2) for long pages during load.

A more detailed approach might look something like this:
 * maintain a hashtable in nsCSSStyleSheet.cpp much like the one used for event
state selectors or attribute selectors, hashing all selectors with any of these
"child-counting" selectors (in which I include :empty).  There would also be a
global variable(s) to indicate whether any nth-last, last-of-type, or
nth-last-of-type were used.  This would probably allow for the necessary
optimizations.  (Consider that we use :-moz-last-node extensively in quirk.css,
and this actually leads to real bugs due to this bug.)

I should probably describe this in a little more detail at some point, or just
implement it.

It would be pretty easy to fix bug 73586 with this type of approach, but bug
229915 would probably be a little more work.  I need to think about that.
Comment 13 Boris Zbarsky [:bz] (still a bit busy) 2004-05-29 11:59:52 PDT
Created attachment 149594 [details]
Clearer first-child testcase
Comment 14 Boris Zbarsky [:bz] (still a bit busy) 2004-05-29 12:03:00 PDT
Created attachment 149595 [details]
Clearer last-child testcase
Comment 15 David Baron :dbaron: ⌚️UTC-10 2004-06-04 13:30:12 PDT
Some other approaches might be feasible now that
nsIDocumentObserver::ContentReplaced no longer exists (which simplifies the
invariants for observer code).
Comment 16 Boris Zbarsky [:bz] (still a bit busy) 2004-08-06 14:18:26 PDT
*** Bug 254598 has been marked as a duplicate of this bug. ***
Comment 17 bugzilla 2005-07-07 10:39:31 PDT
I was just wondering how this bug is being fixed.  Is it planned to be in for
Firefox 1.1?  Or is it for a latter date?
Comment 18 David Baron :dbaron: ⌚️UTC-10 2005-10-14 22:53:44 PDT
*** Bug 303775 has been marked as a duplicate of this bug. ***
Comment 19 Arpad Borsos [:Swatinem] 2006-04-02 11:02:59 PDT
This bug also applies to :only-child. Could someone change the summary accordingly?
Comment 20 Justin Wood (:Callek) 2006-04-02 19:58:50 PDT
boris/david, should I file a new bug re: c#19; or morph this one to include it, I am unsure exactly how similar the issue is in your mind(s).
Comment 21 Timwi 2007-05-08 06:05:53 PDT
This bug affects not only pages that change dynamically; it also affects pages that are simply slow to load. The :last-child CSS rule is (wrongly) applied to all elements that were the last child at some point in the middle of rendering an unfinished page, even if additional elements followed it later.
Comment 22 David Baron :dbaron: ⌚️UTC-10 2007-07-04 00:07:20 PDT
So I think I have a strategy for fixing this bug, bug 98997, and bug 229915.  We should set bits on nsINode (which means we need to mark some more nsINode flags an not reserved for implementations) that mean:
 1. element has an :empty or :-moz-only-whitespace selector
 2. arbitrary operations on children of the element (including append) require a reresolve on the element
 3. append requires a reresolve on the element's last child; other operations on children of the element require a reresolve of the element
 4. append requires no changes, but other operations on children of the element require a reresolve of the element

I'm not sure if we really need the distinction between (3) and (4).  We need (1) separate because of the pile of :-moz-only-whitespace rules in quirk.css -- this would be much easier if we moved that margin collapsing quirk into C++.

SelectorMatches and SelectorMatchesTree would then set these bits *any* time they tried to match one of the problematic selectors (match or no).  This will guarantee that we'll always have them set if the change might matter.  We should move the problematic selectors to the end of SelectorMatches so they get set less often (from least to most problematic).
Comment 23 Timwi 2007-07-04 04:36:06 PDT
Correct me if I'm wrong, but the difference between (3) and (4) appears to be that under (4), :last-child would still be broken.
Comment 24 David Baron :dbaron: ⌚️UTC-10 2007-07-04 09:26:46 PDT
:last-child would set (3).  If we didn't make the distinction, there would only be (3) and not (4).
Comment 25 Elmar Ludwig 2008-01-25 13:02:02 PST
*** Bug 414043 has been marked as a duplicate of this bug. ***
Comment 26 David Baron :dbaron: ⌚️UTC-10 2008-02-19 12:46:02 PST
Fix by checkin of bug 401291 to trunk, 2008-02-18 22:17 -0800.

I included tests for this bug in that landing.

Unfortunately when I mentioned this bug in the checkin comment, I cited the wrong bug number (bug 75386) in the checkin comment.
Comment 27 David Baron :dbaron: ⌚️UTC-10 2008-02-19 12:56:31 PST
*** Bug 357811 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.