1124652 - Gecko doesn't pass Element-matches.html

Status: RESOLVED INVALID

(Core :: DOM: Core & HTML, defect)

Description

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

Not sure if spec, test or implementation bug.

Comment 1

[Boris Zbarsky [:bzbarsky]]

So I see a few classes of failures:

1)  The test is doing things like:

  foo.matches(">*")

due to running 

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

The big comment in http://w3c-test.org/dom/nodes/selectors.js claims "These selectors are intended to be used with the find(), findAll() and matches() methods."

What the spec says for matches() is at https://dom.spec.whatwg.org/#dom-element-matches and is:

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

Per http://dev.w3.org/csswg/selectors/#parse-a-selector the string ">*" is not valid.  It would be valid per <http://dev.w3.org/csswg/selectors/#parse-relative-selector>, 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.

Comment 2

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

https://github.com/w3c/web-platform-tests/pull/1577

Comment 3

[Lachlan Hunt]

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.

http://www.w3.org/TR/selectors-api2/

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.