Bug 182048

Summary:

Fetch response should copy its url from the request if null

Product:

WebKit

Reporter:

youenn fablet <youennf>

Component:

Service Workers

Assignee:

youenn fablet <youennf>

Status:

RESOLVED FIXED

Severity:

Normal

CC:

achristensen, beidson, cdumez, commit-queue, dbates, ews-watchlist, japhet, ryanhaddad, webkit-bug-importer

Priority:

Keywords:

InRadar

Version:

WebKit Nightly Build

Hardware:

Unspecified

OS:

Unspecified

Attachments:

Description	Flags
Patch	none

youenn fablet

Reported 2018-01-24 07:43:27 PST

As per fetch spec, fetch response should copy the request url list if its own is empty. In WebKit terms, it means that the response.url() should be copied from request if null. This is done for network loads but not always for service worker loads.

Attachments
Patch (5.80 KB, patch) 2018-01-24 07:46 PST, youenn fablet	no flags	Details Formatted Diff Diff
View All Add attachment proposed patch, testcase, etc.

youenn fablet

Comment 1 2018-01-24 07:46:02 PST

<rdar://problem/36781554>

youenn fablet

Comment 2 2018-01-24 07:46:35 PST

Created attachment 332163 [details] Patch

WebKit Commit Bot

Comment 3 2018-01-24 10:10:34 PST

Comment on attachment 332163 [details] Patch Clearing flags on attachment: 332163 Committed r227531: <https://trac.webkit.org/changeset/227531>

WebKit Commit Bot

Comment 4 2018-01-24 10:10:35 PST

All reviewed patches have been landed. Closing bug.

Ryan Haddad

Comment 5 2018-01-24 17:50:37 PST

API test WebKit.PreventImageLoadWithAutoResizingTest is failing the assertion added in this change on macOS bots. TIMEOUT WebKit.PreventImageLoadWithAutoResizingTest ASSERTION FAILED: !response.url().isNull() /Volumes/Data/slave/highsierra-debug/build/Source/WebCore/loader/DocumentLoader.cpp(754) : void WebCore::DocumentLoader::responseReceived(const WebCore::ResourceResponse &) 1 0x1221773fd WTFCrash 2 0x113f19452 WebCore::DocumentLoader::responseReceived(WebCore::ResourceResponse const&) 3 0x113f15528 WebCore::DocumentLoader::handleSubstituteDataLoadNow() 4 0x113f3a466 WTF::RunLoopTimer<WebCore::DocumentLoader>::fired() 5 0x1221d9b51 WTF::timerFired(__CFRunLoopTimer*, void*) 6 0x7fff2853c0a4 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ 7 0x7fff2853bd24 __CFRunLoopDoTimer 8 0x7fff2853b81a __CFRunLoopDoTimers 9 0x7fff28532feb __CFRunLoopRun 10 0x7fff285323d7 CFRunLoopRunSpecific 11 0x7fff2783fe26 RunCurrentEventLoopInMode 12 0x7fff2783fb96 ReceiveNextEventCommon 13 0x7fff2783f914 _BlockUntilNextEventMatchingListInModeWithFilter 14 0x7fff25b0af5f _DPSNextEvent 15 0x7fff262a0b4c -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] 16 0x7fff25affd6d -[NSApplication run] 17 0x7fff25acef1a NSApplicationMain 18 0x7fff501a542f _xpc_objc_main 19 0x7fff501a4082 xpc_main 20 0x10bf3c12b main 21 0x7fff4fed8115 start https://build.webkit.org/builders/Apple%20High%20Sierra%20Debug%20WK1%20%28Tests%29/builds/2026

youenn fablet

Comment 6 2018-01-24 17:53:26 PST

Will look at the failure tomorrow

youenn fablet

Comment 7 2018-01-25 13:43:29 PST

(In reply to youenn fablet from comment #6) > Will look at the failure tomorrow Patch at https://bugs.webkit.org/show_bug.cgi?id=182112

Note You need to log in before you can comment on or make changes to this bug.