221531 - clean up selector matching code

Status: RESOLVED FIXED

(Core :: CSS Parsing and Computation, defect)

Description

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

I have a patch with some cleanup in SelectorMatchesTree and SelectorMatches.

Comment 1

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Attachment: patch (diff -u)

The changes are:
 * remove extra |if| around loop, and convert it from |while| to |for|.
 * remove extra test for |result|
 * rename |curdata| -> |prevdata| and |newdata| -> |data|.
 * use |IsContentOfType| instead of |GetTag|

Comment 2

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Attachment: patch (diff -uw)

Comment 3

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 132845 [details] [diff] [review]
patch (diff -uw)

>Index: nsCSSStyleSheet.cpp
>+    // For the appropriate content (whether parent or previous sibling)
>+    // to check next, if we don't already have a RuleProcessorData
>     // for it, create one.

"If we don't already have a RuleProcessorData for the next appropriate content
(whether parent or previous sibling), create one."

r+sr=bzbarsky with that.

Comment 4

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Fix checked in to trunk, 2003-10-13 14:54 -0700.

Comment 5

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Seems like this might have pushed up Tp slightly ... is that possible?

Comment 6

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

I don't see any noticeable change on btek, and I doubt it would have.

Comment 7

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Something pushed btek from mostly below 1000ms to mostly above 1000ms and I
thought it might have been this patch, but it's so noisy that it's hard to tell.