Bug 152051 – [Streams API] Import the web-platform-tests directly from the spec

• Component: New Bugs
• Status: RESOLVED FIXED

[Xabier Rodríguez Calvar]

[Streams API] Import the web-platform-tests directly from the spec

[Xabier Rodríguez Calvar]

Created attachment 266983 [details]
Patch

[youenn fablet]

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?

[Xabier Rodríguez Calvar]

(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.

[youenn fablet]

Comment on attachment 266983 [details]
Patch

r=me

[Xabier Rodríguez Calvar]

Created attachment 266989 [details]
Patch for landing

[WebKit Commit Bot]

Comment on attachment 266989 [details]
Patch for landing

Clearing flags on attachment: 266989

Committed r193824: <http://trac.webkit.org/changeset/193824>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.