Bug 155886 – [Fetch API] Add basic loading of resources for Workers

• Status: RESOLVED
• Resolution: FIXED
• Component: WebCore Misc.

[youenn fablet]

Following on bug 155637, we should add basic loading of resources for Workers.

[youenn fablet]

Created attachment 274913 [details]
Patch

[Alex Christensen]

Comment on attachment 274913 [details]
Patch

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

A small change with lots of test progressions!  This is great, but r- because of a small unchecked pointer issue:

> Source/WebCore/Modules/fetch/DOMWindowFetch.cpp:42
>  void DOMWindowFetch::fetch(DOMWindow& window, FetchRequest* input, const Dictionary& dictionary, DeferredWrapper&& promise)
>  {
> +    ASSERT(input);

We should make input a FetchRequest&, then we should check the pointer before calling this.  Otherwise this could lead to null pointer issues.

> Source/WebCore/Modules/fetch/WorkerGlobalScopeFetch.cpp:43
> +void WorkerGlobalScopeFetch::fetch(WorkerGlobalScope& scope, FetchRequest* input, const Dictionary& dictionary, DeferredWrapper&& promise)
>  {
> -    promise.reject(ASCIILiteral("Fetch is not yet implemented"));
> +    ASSERT(input);

ditto

[youenn fablet]

Comment on attachment 274913 [details]
Patch

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

>> Source/WebCore/Modules/fetch/DOMWindowFetch.cpp:42
>> +    ASSERT(input);
> 
> We should make input a FetchRequest&, then we should check the pointer before calling this.  Otherwise this could lead to null pointer issues.

Changing that requires updating the binding generator.
I agree this would be a good move.
I 'd like if possible to ship that patch before updating the binding generator.

[Alex Christensen]

Then add null checks, early returns, and fixme comments.  Loading code with unchecked null pointers causes scary problems.

[youenn fablet]

(In reply to comment #4)
> Then add null checks, early returns, and fixme comments.  Loading code with
> unchecked null pointers causes scary problems.

These null checks would be redundant with binding generated code.
Let's fix the binding generator then.

[youenn fablet]

Created attachment 275214 [details]
Rebasing

[Alex Christensen]

Comment on attachment 275214 [details]
Rebasing

r=me

[Build Bot]

Comment on attachment 275214 [details]
Rebasing

Attachment 275214 [details] did not pass mac-ews (mac):
Output: http://webkit-queues.webkit.org/results/1071238

New failing tests:
imported/w3c/web-platform-tests/fetch/api/basic/request-headers-worker.html

[Build Bot]

Created attachment 275217 [details]
Archive of layout-test-results from ews100 for mac-yosemite

The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: ews100  Port: mac-yosemite  Platform: Mac OS X 10.10.5

[Build Bot]

Comment on attachment 275214 [details]
Rebasing

Attachment 275214 [details] did not pass mac-wk2-ews (mac-wk2):
Output: http://webkit-queues.webkit.org/results/1071250

New failing tests:
imported/w3c/web-platform-tests/fetch/api/basic/request-headers-worker.html

[Build Bot]

Created attachment 275218 [details]
Archive of layout-test-results from ews106 for mac-yosemite-wk2

The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: ews106  Port: mac-yosemite-wk2  Platform: Mac OS X 10.10.5

[Build Bot]

Comment on attachment 275214 [details]
Rebasing

Attachment 275214 [details] did not pass ios-sim-ews (ios-simulator-wk2):
Output: http://webkit-queues.webkit.org/results/1071247

New failing tests:
imported/w3c/web-platform-tests/fetch/api/basic/request-headers-worker.html

[Build Bot]

Created attachment 275219 [details]
Archive of layout-test-results from ews121 for ios-simulator-wk2

The attached test failures were seen while running run-webkit-tests on the ios-sim-ews.
Bot: ews121  Port: ios-simulator-wk2  Platform: Mac OS X 10.10.5

[Build Bot]

Comment on attachment 275214 [details]
Rebasing

Attachment 275214 [details] did not pass mac-debug-ews (mac):
Output: http://webkit-queues.webkit.org/results/1071230

New failing tests:
imported/w3c/web-platform-tests/fetch/api/basic/request-headers-worker.html

[Build Bot]

Created attachment 275220 [details]
Archive of layout-test-results from ews113 for mac-yosemite

The attached test failures were seen while running run-webkit-tests on the mac-debug-ews.
Bot: ews113  Port: mac-yosemite  Platform: Mac OS X 10.10.5

[youenn fablet]

Created attachment 275272 [details]
Patch for landing

[youenn fablet]

(In reply to comment #14)
> Comment on attachment 275214 [details]
> Rebasing
> 
> Attachment 275214 [details] did not pass mac-debug-ews (mac):
> Output: http://webkit-queues.webkit.org/results/1071230
> 
> New failing tests:
> imported/w3c/web-platform-tests/fetch/api/basic/request-headers-worker.html

Mac HTTP backend seems to add a Content-Length: 0 header, while soup backend does not.
I added a specific GTK baseline for that test in the landing patch.

[WebKit Commit Bot]

Comment on attachment 275272 [details]
Patch for landing

Clearing flags on attachment: 275272

Committed r198891: <http://trac.webkit.org/changeset/198891>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.