This makes it clearer that, unlike how SizeOf*() functions usually work, this
doesn't measure any children hanging off the array.
And do likewise for nsTObserverArray.
Ignoring sheets added by add-ons, all sheets in the eAgentSheet and
eUserSheet levels should come from the nsLayoutStylesheetCache and thus
allow multiple documents to make use of a shared rule processor.
AllocateByObjectID() is infallible. Therefore the |operator new| of nsFrameList,
nsLineBox and nsRuleNode are too, as is nsRuleNode::CreateRootNode().
The patch also removes a couple of comments duplicated in both .h and .cpp
files.
For the poisoning in nsPresArena.cpp I made it print out the details, because
that seems useful. For the other I simply removed the printing of the
unexpected value because that seems less important; we have countless
assertions like that elsewhere in the codebase that don't print the unexpected
value.
I confirmed that we're actually using this codepath by manually testing
<input type=color>: it works with the patch, but if I comment out the
call to nsHTMLCSSStyleSheet::PseudoElementRulesMatching from
nsStyleSet::RuleNodeWithReplacement, then the color swatch breaks, which
proves that we're depending on the code.
I think I included this in the queue because it is needed for patch 22,
although I've forgotten the full reasoning.
Note that this means that when we start transitions, we post restyles
that are processed during the current restyling operation, rather than
in a later phase. This depends on patch 11, which makes the transition
manager skip style changes that it posts while starting transitions, to
ensure that this doesn't lead to an infinite loop. This also depends on
patch 16, which only consumes restyle data for the primary frame, to
ensure that the animation restyles posted are processed properly. It
also depends on patch 14, which makes us retain data on finished
transitions, to avoid triggering extra transitions on descendants when
both an ancestor and a descendant transition an inherited property, and
the descendant does so faster.
This fixes a known failure in layout/style/test/test_animations.html and
test_animations_omta.html (as visible in the patch). I believe this is
because this patch changes us to compute keyframe values for animations
on top of a style context *with* animation data rather than one without,
which means what we're computing them on top of changes each time. (The
purpose of patch 3 was to avoid this in the case where avoiding it
matters, i.e., implicit 0% and 100% keyframes.)
I confirmed that this assertion fires (along with the other failures)
when running layout/style/test/test_transitions_events.html with patch 3
but not patch 1.
Without this patch, patch 3 will cause bugs where we'll never remove the
cover rule we create during the process of starting a transition. This
won't actually be problematic during the transition, since the
transition will overwrite it, but once the transition completes, the
cover rule will still be around, and we'll be stuck with the
pre-transition value instead of the post-transition value.
It's possible it also fixes existing bugs prior to the patch series in
this bug.
I originally wrote this to see if it would fix bug 1086937, but it
didn't.
Note that this conflicts a bit with the patch in bug 1085769; whoever
lands second will have some merging (though it shouldn't be difficult).
The updating of the style rule is needed as part of the animation-only
style update, but it shouldn't be in the general restyling code, so it
has moved there.
