We've been getting several CI failures recently from Node-cloneNode.html taking longer than 70 seconds to pass. (Even on my local machine which is pretty beefy, it takes around 45 seconds.) I will disable it for now.
Similarly, many tests involving ranges (e.g. under dom/ranges or selection) take a very long time to pass. I will not be disabling those yet, although we might have to at some point.
It'd be lovely if we could dig in to what is slow about these tests. I suspect that jsdom could be faster; maybe we have some O(n^2) algorithm or something. This seems especially likely for ranges.
If we think a given case is just a very slow test, then we could try to split it up by modifying the upstream WPT repo, e.g. like web-platform-tests/wpt#21881 did.
We've been getting several CI failures recently from
Node-cloneNode.htmltaking longer than 70 seconds to pass. (Even on my local machine which is pretty beefy, it takes around 45 seconds.) I will disable it for now.Similarly, many tests involving ranges (e.g. under
dom/rangesorselection) take a very long time to pass. I will not be disabling those yet, although we might have to at some point.It'd be lovely if we could dig in to what is slow about these tests. I suspect that jsdom could be faster; maybe we have some O(n^2) algorithm or something. This seems especially likely for ranges.
If we think a given case is just a very slow test, then we could try to split it up by modifying the upstream WPT repo, e.g. like web-platform-tests/wpt#21881 did.