(This change needs to be done upstream and then synced.) Some of my tests imported from the W3C, for Range in particular, take multiple long lists of ranges and/or points and/or nodes and run some test on every possible permutation of them. This takes forever and tends to cause timeouts. It should be possible to greatly reduce the number of tests that are run without reducing the coverage too much. I have, however, caught some bugs in UAs that only arise in very particular circumstances -- like an Opera crash if you extractContents() a range that starts at offset 0 in a comment -- so some thought should be given to how best to do this.

I wrote some updates and filed a pull request at the new upstream: https://github.com/w3c/web-platform-tests/pull/265 I'm back to school tomorrow afternoon, so I might not have time to write up a patch to Gecko to incorporate the changes until my next break (in five weeks). Ms2ger could do it from here without too much work, though, if I don't get to it.

Isn't it browser's bug? Is it correct to work around the OOM error in the test side? Any malicious pages can do the same to make a DoS attack, after all.

Web pages can use as much memory as they want, until something OOMs. If we want OOM tests we can have such, but tests for Range should doing stuff which is known to be slow and memory hungry. Range tests should test that the Range API is implemented correctly.

er, shouldn't be ...

The issue here isn't that the tests are using APIs that are prone to DoS, it's just that a huge number of tests are being run per file. Intelligently reducing the number of tests in a way that doesn't hurt coverage much is just better use of everyone's resources. (I could also fix the fact that some test files use O(N) memory in number of tests, but that's not worth it if the number of tests is cut down anyway to save on runtime.)