Bug 205225

Summary: WebSWServerConnection::startFetch() should never fail synchronously
Product: WebKit Reporter: Chris Dumez <cdumez>
Component: Service WorkersAssignee: Chris Dumez <cdumez>
Status: RESOLVED FIXED    
Severity: Normal CC: beidson, commit-queue, ggaren, webkit-bug-importer, youennf
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
See Also: https://bugs.webkit.org/show_bug.cgi?id=205261
Attachments:
Description Flags
Patch none

Chris Dumez
Reported 2019-12-13 16:10:34 PST
WebSWServerConnection::startFetch() should never fail synchronously. If it does, it will confuse the NetworkResourceLoader. NetworkResourceLoader::serviceWorkerDidNotHandle() will get called *before* NetworkResourceLoader::m_serviceWorkerFetchTask has been sent, which means that we would not properly deal with redirects. Worse, the call site which creates the ServiceWorkerFetchTask would then null out m_networkLoad, which would silently cancel the load that WebSWServerConnection::startFetch() started synchronously.
Attachments
Patch (5.47 KB, patch)
2019-12-13 16:21 PST, Chris Dumez 		no flags
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Chris Dumez
Comment 1 2019-12-13 16:10:47 PST
<rdar://problem/57490508>
Chris Dumez
Comment 2 2019-12-13 16:21:25 PST
Created attachment 385654 [details] Patch
Geoffrey Garen
Comment 3 2019-12-14 11:59:10 PST
r=me
WebKit Commit Bot
Comment 4 2019-12-14 13:49:18 PST
Comment on attachment 385654 [details] Patch Clearing flags on attachment: 385654 Committed r253528: <https://trac.webkit.org/changeset/253528>
WebKit Commit Bot
Comment 5 2019-12-14 13:49:19 PST
All reviewed patches have been landed. Closing bug.
youenn fablet
Comment 6 2019-12-16 02:26:59 PST
http/wpt/service-workers/postMessage-fetch-order.https.html fails consistently. The spec does not mandate the order between fetch and postMessage since these are different sources so we could update the test accordingly. An alternative would be to only delay the didNotHandle case, which would remove an unnecessary dispatch in the usual case.
Note You need to log in before you can comment on or make changes to this bug.