[Fetch API] Ensure response cloning works when data is loading

[youenn fablet]

When data is loading, cloning is not working as FetchBody contains no data.

[youenn fablet]

Created attachment 286852 [details]
Patch

[youenn fablet]

Created attachment 286971 [details]
Improving test style

[Darin Adler]

Comment on attachment 286971 [details]
Improving test style

View in context: https://bugs.webkit.org/attachment.cgi?id=286971&action=review

> Source/WebCore/Modules/fetch/FetchResponse.cpp:140
>      if (m_response.m_readableStreamSource) {
> -        m_response.m_readableStreamSource->close();
> -        m_response.m_readableStreamSource = nullptr;
> +        // Let's close the stream except if we have data to enqueue.
> +        if (m_response.m_body.type() != FetchBody::Type::Loaded) {
> +            m_response.m_readableStreamSource->close();
> +            m_response.m_readableStreamSource = nullptr;
> +        }
>      }

In the case where we don’t close the stream here, what closes the stream?

Why not use && instead of nested if statements?

[youenn fablet]

(In reply to comment #3)
> Comment on attachment 286971 [details]
> Improving test style
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=286971&action=review
> 
> > Source/WebCore/Modules/fetch/FetchResponse.cpp:140
> >      if (m_response.m_readableStreamSource) {
> > -        m_response.m_readableStreamSource->close();
> > -        m_response.m_readableStreamSource = nullptr;
> > +        // Let's close the stream except if we have data to enqueue.
> > +        if (m_response.m_body.type() != FetchBody::Type::Loaded) {
> > +            m_response.m_readableStreamSource->close();
> > +            m_response.m_readableStreamSource = nullptr;
> > +        }
> >      }
> 
> In the case where we don’t close the stream here, what closes the stream?

When type is Loaded, FetchBody has some data, which means the data was not enqueued in the stream. On the first read request, FetchBody::consumeAsStream will enqueue the data and close the stream.
I'll update the comment.

Overall, there is some complexity added by the idea of enqueuing data only on the first read call. Maybe we should simplify this and enqueue data as soon as the stream is created.

> Why not use && instead of nested if statements?

Right, I'll fix that.

[youenn fablet]

Created attachment 287249 [details]
Patch for landing

[WebKit Commit Bot]

Comment on attachment 287249 [details]
Patch for landing

Clearing flags on attachment: 287249

Committed r205110: <http://trac.webkit.org/changeset/205110>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.