MattiasBuelens
commented
4 years ago Okay, the tests really don't like having the ponyfill come from a different VM. It breaks in all sorts of ways.
webidl2.js contains the following check:
let proto = this;
while (proto !== Object.prototype) {
// ...
proto = Object.getPrototypeOf(proto);
}However, the "parent VM's" Object is injected into the test VM, so any instance of a class that's defined inside the test VM (like Constructor) does not have this particular Object.prototype in its prototype chain... I could work around this by checking for Object.getPrototypeOf(proto) !== null instead, but it feels weird.
Then there's the exposed_in function in idlharness.js, which checks what sort of environment we're running in to figure out which IDL definitions should be exposed. Of course, this function doesn't expect a Node-like environment, so it throws an error. Again, I could work around this by having it assume a worker-like environment, but it's yet another hack.
Finally, there are these tests in idlharness.js which check that an IDL object without a constructor cannot be called as a function or as a constructor. In that case, the VM throws an instance of its original version of TypeError, even if we have already replaced the global TypeError. This causes a test failure on this line, since e is an instance of the test VM's original TypeError, while constructor is the global TypeError that has been replaced with the parent VM's version. I really don't know how to fix this one: if I let the test VM keep its own original TypeError instead, then all of the other tests that deal with TypeErrors originating from the ponyfill (and thus coming from the parent VM) will fail... 😕
One way to fix these issues would be to load the ponyfill inside of the test VM, rather than loading it in the "parent VM" and copying it into the test VM's global scope. This would be closer to what the reference implementation does with WPT runner, but it would be very different from the existing Node WPT tests. I... don't really know how I feel about this. 🤷
targos
Ethan-Arrowood
mcollina
ronag
benjamingr
jimmywarting
This implements the WHATWG Streams API using the ES2018 ponyfill build from web-streams-polyfill.
The WPT set up is based off of @joyeecheung's work in #2. Many thanks for that! 😄
To do list:
promise_test), this means that tests can interfere with each other. This is especially bad for the "patched globals" tests, which will literally break the API during the test.completionCallbackis called before we start the next test. I'll try implementing it here first, to see if it works. Hopefully we can upstream that afterwards? 🙏PromiseorUint8Arrayfrom there. However, the tests are run inside a separate VM context, so when it tries to compare whether e.g.ReadableStreamBYOBRequest.viewis aUint8Array, it's using a different global forUint8Arraythan the polyfill.ReadableStream[Symbol.asyncIterator]()has%AsyncIteratorPrototype%as its prototype. As far as I know, there's no way to replace that...ReadableStream.pipeTo()uses anAbortSignal. Currently, I'm using a separate polyfill for that.AbortSignalfrom Node 15! 😁ReadableStream.pipeTo()needs to reject with aDOMExceptionwhen it is aborted using a signal, which is also tested by WPT.--expose-internals, I can retrieve theDOMExceptionimplementation from Node itself. It's even given as an example in the test driver's README! 😅