Mozilla 0.9.8 doesn't accept ":last-of-type" selector as specified in
http://www.w3.org/TR/2001/CR-css3-selectors-20011113/.
When viewing an XHTML 1.1 page with a stylesheet that uses a selector like:
li:last-of-type
one doesn't see the effect of this style rule. (An example of such a page you
can find at the URL linked with this report.)
Note, that a similar ":last-child" pseudoclass selector seems to be processed by
Mozilla the right way.

Comment on attachment 308232[details][diff][review]
patch
>+++ b/layout/style/nsCSSRuleProcessor.cpp
>+ else if (nsCSSPseudoClasses::firstOfType == pseudoClass->mAtom ||
>+ nsCSSPseudoClasses::lastOfType == pseudoClass->mAtom ||
>+ nsCSSPseudoClasses::onlyOfType == pseudoClass->mAtom) {
Would it make sense to also combine firstChild/lastChild/onlyChild like this as well, now that we have this index-caching thing in place? Followup bug is fine.
r+sr=bzbarsky

(In reply to comment #13)
> Would it make sense to also combine firstChild/lastChild/onlyChild like this as
> well, now that we have this index-caching thing in place? Followup bug is
> fine.
I don't see why -- those are computationally much less complex (except for bizarre edge cases with ridiculous amounts of text or comments -- though maybe that's not quite as bizarre as I think) since the looping over children can stop at the first/last child element.

With the changes in this patch, GetNthIndex will also stop at the first/last child element if we're doing the aCheckEdgeOnly case. So I think the computational complexity for a single selector occurrence is about the same. The difference is that GetNthIndex will cache, so if the selector occurs more than once we win.
And yeah, having a lot of text is not that bizarre, really.