Pass remaining Web Platform Tests for selectors #10
Comments
|
The commit you pushed while I was creating this issue solved the failures related to namespaces 🎉 |
|
@Zirro correct, there was a specific commit for the namespace issue... I hope that commit finally solves both the remaining SVG and more generally the XML issues with mixed-content. I am also ready to commit the changes needed for the "duplicate IDs", just need a bit more time to do some code lifting and cleanup. The last commit I did is also a performance improvement for comma separated groups of selectors, they where fast already but now they should be even faster and the code is smaller. |
|
I've just tested beta2 with jsdom, and unfortunately the SVG tests are still an issue. I don't know if it helps, but some quick debugging shows that it ends up running this code at one point where e.nodeName is compared against uppercase "SVG": (function(s
/*``*/) {
"use strict";return function Resolver(c,f,x){var r=[],e,n,o,j=-1,k=-1;c=c(true);main:while(e=c[++k]){if((e.nodeName=="SVG")){r[++j]=c[k];if(f(c[k])){break main;}continue main;}}return r; }
})I'll have more time for debugging in a few days. |
|
@Zirro thank you for noticing the issue, clearly every strangeness you notice and report might help. I was forced to accept a minor performance loss to try a new path aimed at resolving the mixed-namespace problem. I hope this solves the SVG and similar issues with tag names upper/lower case. |
|
Yes - the latest commits have finally solved the SVG problem, as well as the one with duplicate IDs! 🎉 Unfortunately, there are also some new failures. 924d5b4 appears to be the cause for most of them, as several more tests pass if I revert it or set With FASTCOMMA set to false, there's still a failure where I'll need some time to figure out if the other issues are in jsdom or nwsapi, but thanks for resolving everything related to mixed namespaces. |
|
@Zirro thank you for the feedback, really appreciated (and needed). I normally test everything with standard browsers first, then when I publish a new release to npm I test with jsdom by simply replacing current "nwmatcher-noqsa.js" with the content of the new "nwsapi". I understand this is a bit of a skew procedure but as soon as I have more spare time I am going to dig myself a bit more into Can you share more info about how you do testing of WPT selectors, I have tried I can do it easily from a browser but I will prefer doing the same from terminal running "node <file.js>" that will allow me to test and benchmark without having to run the complete test suite each time. For the "" problem you noticed I don't know what to say now, but I will check that out if you send me the test or the link were I can see that problem. As a first guess the problem might be in a different place because the "firstElementChild" property should not return a text node in any circumstance that I am aware of. The line you pointed out (L314) is needed by the engine to handle elements in a DocumentFragment (nodeType 11) to allow using native gEBTN method to collect nodes from a fragment since DocumentFragment nodes do not have those methods available in their prototype. I am writing down details of the process bound to the "FASTCOMMA" flag as you asked in another message to keep things apart. |
|
@Zirro about the comma group selectors and the "FASTCOMMA" configuration flag ... The basic is that the "collect()" method (L1442-1480), in the main "else" block, is caching the needed HTMLCollection lists (which are live lists) needed in resolution of comma groups selectors. The objective is to resolve comma group selectors in a faster way but at the same time ensure that those initial HTMLCollection lists have not been changed since their last caching time to ensure error free So, as an example, for the "div.notes, span.detail" selector I am caching the "div" HTMLCollection and the "span" HTMLCollection" and then build the usual resolver function that only checks these elements for their corresponding class names without checking the tag names again. Since I do this in "document order" there is no need to go through an extra reordering pass nor to check the resulting array for uniqueness, which further improves the process performances. A second example, to better explain a different case where this is important. For a selector like "h1, h2, h3, h4, h5, h6", used to automate TOC building for HTML documents, it will be even faster because the six HTMLCollection lists alone will makeup the result with only one pass to have them returned in "document order". Again no need to perform extra reorder/unique passes. Not sure the explanation was clear enough, you will have to bear with my English skills. |
Absolutely - you can use the
You will also need to change the list of failing tests -
Yeah, the problem is not that it returns a text node, but it returns <body>No elements here - only text</body>Thanks for explaining It's still strange that it would cause these failures though, but perhaps it has some unintended side-effect in jsdom. I will debug it over the weekend. |
nwsapi is nearly passing all Web Platform Tests that browsers do, which is very exciting. Since these tests are used by browsers to ensure that they are compatible with each other, it would be excellent if it could pass the final ones as well. These are the last tests from the
dom/nodes/directory which pass in browsers, but fail in nwsapi:dom/nodes/ParentNode-querySelector-All.html:
dom/nodes/Element-closest.html:
Let me know if you have any questions about the tests.
The text was updated successfully, but these errors were encountered: