[Streams API] Import the web-platform-tests directly from the spec
Created attachment 266983 [details] Patch
Comment on attachment 266983 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=266983&action=review > LayoutTests/imported/w3c/web-platform-tests/service-workers/service-workers/resources/README.txt:2 > +version at the VERSION.txt file. Update the last sentence? > LayoutTests/imported/w3c/web-platform-tests/streams-api/README.txt:2 > +file. Ditto. > LayoutTests/imported/w3c/web-platform-tests/streams-api/byte-length-queuing-strategy-expected.txt:8 > +PASS ByteLengthQueuingStrategy's highWaterMark property can be set to anything These are regular tests so are passing. > LayoutTests/imported/w3c/web-platform-tests/streams-api/byte-length-queuing-strategy-expected.txt:9 > +FAIL Load byte-length-queuing-strategy.js with SharedWorker assert_unreached: SharedWorker is unavailable Reached unreachable code These are regular tests run in a SharedWorker, hence failing as not supported. > LayoutTests/imported/w3c/web-platform-tests/streams-api/byte-length-queuing-strategy-expected.txt:10 > +FAIL Untitled undefined is not an object (evaluating 'navigator.serviceWorker.getRegistration') These are regular tests run in a ServiceWorker, hence failing as not supported. > LayoutTests/imported/w3c/web-platform-tests/streams-api/byte-length-queuing-strategy-expected.txt:11 > +FAIL Can construct a ByteLengthQueuingStrategy with a valid high water mark Can't find variable: ByteLengthQueuingStrategy This is a regular test run in a Worker. It should pass once ReadableStream is exposed to Worker. > LayoutTests/imported/w3c/web-platform-tests/streams-api/readable-streams/brand-checks-expected.txt:24 > +PASS ReadableStreamReader enforces a brand check on its argument A bit strange that this test is passing in Worker? > LayoutTests/imported/w3c/web-platform-tests/streams-api/readable-streams/brand-checks-expected.txt:29 > +PASS ReadableStreamController enforces a brand check on its argument Ditto? > LayoutTests/imported/w3c/web-platform-tests/streams-api/readable-streams/cancel-expected.txt:2 > +FAIL ReadableStream cancellation: integration test on an infinite stream derived from a random push source promise_test: Unhandled rejection with value: object "Error: forced error" This is the flaky test that needs more investigation as explained in the logs. > LayoutTests/imported/w3c/web-platform-tests/streams-api/readable-streams/general-expected.txt:4 > +FAIL ReadableStream instances should have the correct list of properties assert_false: method should be non-enumerable expected false got true Also failing in past test suite > LayoutTests/imported/w3c/web-platform-tests/streams-api/readable-streams/general-expected.txt:8 > +FAIL ReadableStream start should be called with the proper parameters assert_false: close should be non-enumerable expected false got true Also failing in past test suite > LayoutTests/imported/w3c/web-platform-tests/streams-api/readable-streams/pipe-through-expected.txt:5 > +FAIL ReadableStream.prototype.pipeThrough should rethrow errors from accessing pipeTo, readable, or writable assert_unreached: pipeTo should not be called Reached unreachable code Why is it failing? Is the implementation faulty? > LayoutTests/streams/reference-implementation/readable-stream-templated.html:348 > templatedRSClosed('ReadableStream (closed via call in start)', function() { We should investigate whether to keep those tests (and their neighbours) I guess? Will they be ported at some point or are they redundant?
(In reply to comment #2) > > LayoutTests/imported/w3c/web-platform-tests/service-workers/service-workers/resources/README.txt:2 > > +version at the VERSION.txt file. > > Update the last sentence? > > > LayoutTests/imported/w3c/web-platform-tests/streams-api/README.txt:2 > > +file. > > Ditto. I guess we can fix this at landing time, right? > > LayoutTests/imported/w3c/web-platform-tests/streams-api/byte-length-queuing-strategy-expected.txt:8 > > +PASS ByteLengthQueuingStrategy's highWaterMark property can be set to anything > > These are regular tests so are passing. > > > LayoutTests/imported/w3c/web-platform-tests/streams-api/byte-length-queuing-strategy-expected.txt:9 > > +FAIL Load byte-length-queuing-strategy.js with SharedWorker assert_unreached: SharedWorker is unavailable Reached unreachable code > > These are regular tests run in a SharedWorker, hence failing as not > supported. > > > LayoutTests/imported/w3c/web-platform-tests/streams-api/byte-length-queuing-strategy-expected.txt:10 > > +FAIL Untitled undefined is not an object (evaluating 'navigator.serviceWorker.getRegistration') > > These are regular tests run in a ServiceWorker, hence failing as not > supported. > > > LayoutTests/imported/w3c/web-platform-tests/streams-api/byte-length-queuing-strategy-expected.txt:11 > > +FAIL Can construct a ByteLengthQueuingStrategy with a valid high water mark Can't find variable: ByteLengthQueuingStrategy > > This is a regular test run in a Worker. It should pass once ReadableStream > is exposed to Worker. > > > LayoutTests/imported/w3c/web-platform-tests/streams-api/readable-streams/brand-checks-expected.txt:24 > > +PASS ReadableStreamReader enforces a brand check on its argument > > A bit strange that this test is passing in Worker? > > > LayoutTests/imported/w3c/web-platform-tests/streams-api/readable-streams/brand-checks-expected.txt:29 > > +PASS ReadableStreamController enforces a brand check on its argument > > Ditto? > > > LayoutTests/imported/w3c/web-platform-tests/streams-api/readable-streams/cancel-expected.txt:2 > > +FAIL ReadableStream cancellation: integration test on an infinite stream derived from a random push source promise_test: Unhandled rejection with value: object "Error: forced error" > > This is the flaky test that needs more investigation as explained in the > logs. > > > LayoutTests/imported/w3c/web-platform-tests/streams-api/readable-streams/general-expected.txt:4 > > +FAIL ReadableStream instances should have the correct list of properties assert_false: method should be non-enumerable expected false got true > > Also failing in past test suite > > > LayoutTests/imported/w3c/web-platform-tests/streams-api/readable-streams/general-expected.txt:8 > > +FAIL ReadableStream start should be called with the proper parameters assert_false: close should be non-enumerable expected false got true > > Also failing in past test suite The answer to all these comments is that yes, that's the explanation. In the case of the tests in workers that are passing and they shouldn't, I think we should investigate them when workers are ready, until now, I don't think we can reach a proper conclusion. > > LayoutTests/imported/w3c/web-platform-tests/streams-api/readable-streams/pipe-through-expected.txt:5 > > +FAIL ReadableStream.prototype.pipeThrough should rethrow errors from accessing pipeTo, readable, or writable assert_unreached: pipeTo should not be called Reached unreachable code > > Why is it failing? > Is the implementation faulty? This is a new test so I don't know why it is failing. I'll file a bug and get on it just after landing this. > > LayoutTests/streams/reference-implementation/readable-stream-templated.html:348 > > templatedRSClosed('ReadableStream (closed via call in start)', function() { > > We should investigate whether to keep those tests (and their neighbours) I > guess? > Will they be ported at some point or are they redundant? They are not redundant, they remain here basically because they related to piping and writable streams, which are not ported to web platform yet. Conclusion, I think we could land this, fixing those comments in the txt files.
Comment on attachment 266983 [details] Patch r=me
Created attachment 266989 [details] Patch for landing
Comment on attachment 266989 [details] Patch for landing Clearing flags on attachment: 266989 Committed r193824: <http://trac.webkit.org/changeset/193824>
All reviewed patches have been landed. Closing bug.