Gecko doesn't pass Element-matches.html




4 years ago
4 years ago


(Reporter: Ms2ger, Unassigned)



Firefox Tracking Flags

(Not tracked)





4 years ago
Not sure if spec, test or implementation bug.
So I see a few classes of failures:

1)  The test is doing things like:


due to running 

  runMatchesTest("In-document", doc, scopedSelectors, "html");

The big comment in claims "These selectors are intended to be used with the find(), findAll() and matches() methods."

What the spec says for matches() is at and is:

  Let s be the result of parse a selector from selectors. [SELECTORS] 
  If s is failure, throw a SyntaxError. 

Per the string ">*" is not valid.  It would be valid per <>, I think.  This part clearly looks like a test bug to me.   I think TEST_MATCH should not be set for any of those selectors in scopedSelectors.

2)  The test does something.matches("*", somethingElse) and expects that to act as a scoped selector and match the "something" if it's a descendant of "somethingElse".  But per spec matches() does not take a second context argument.  This is a test bug; this test should not be flagged TEST_MATCH.

In fact, having TEST_MATCH on any of the scopedSelectors is pretty suspect; those that pass more or less do so by accident, afaict.

3)  Some of the non-ASCII tests under scopedSelectors are failing.  They're failing because someone fucked up and didn't read the "Caution: If copying and pasting the folowing non-ASCII classes, ensure unicode normalisation is not performed in the process" comment prominently placed in the validSelectors non-ASCII bits and the similar one for IDs. 

Specifically, the HTML has Táiběi in the class/ID with the á encoded in UTF-8 as 0x61 0xCC 0x81 (an "a" followed by U+0301 COMBINING ACUTE ACCENT) and has the "ě" likewise encoded as an "e" followed by a combining mark.  The same is true of the validSelectors tests in the JS.  But the scopedSelectors tests have the "á" encoded as 0xC3 0xA1, which is U+00E1 LATIN SMALL LETTER A WITH ACUTE, and similar combined char for the "ě".

This, too, is clearly a test bug.
Last Resolved: 4 years ago
Resolution: --- → INVALID

Comment 3

4 years ago
In earlier drafts of the Selectors API 2 spec, matches() did take a relative selector and did take a second argument for refNodes.  See the old WG NOTE.

It appears this has been changed in the more recent DOM spec that superseded Selectors API 2.  So the tests were valid at the time I wrote them, but that spec change makes them invalid.
You need to log in before you can comment on or make changes to this bug.