Layout Test imported/w3c/web-platform-tests/service-workers/service-worker/fetch...
authorcdumez@apple.com <cdumez@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Wed, 7 Feb 2018 00:03:06 +0000 (00:03 +0000)
committercdumez@apple.com <cdumez@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Wed, 7 Feb 2018 00:03:06 +0000 (00:03 +0000)
commitc14bcca118de964c838b03110b2db5c51ff0341e
treeb5dfaf10cf43d0acc51283d2243188663e4af74b
parent11c999f147aa8eea77b04272953a10ffe6fba29d
Layout Test imported/w3c/web-platform-tests/service-workers/service-worker/fetch-waits-for-activate.https.html is a flaky failure on macOS and iOS
https://bugs.webkit.org/show_bug.cgi?id=181392
<rdar://problem/36384136>

Reviewed by Youenn Fablet.

Source/WebKit:

All tasks from the StorageProcess to the WebContent process to update registrations
and service workers state are posted to the runloop. However, the fetch callbacks
do not do so. This means that fetch results might come in out of order with regards
to the registration / service worker state updates. The test was flaky because an
intercepted load would sometimes finish before the task to update the service worker
state to "activated" was processed by the runloop. We address the issue by having
the ServiceWorkerClientFetch callbacks schedule tasks to the runloop too.

* WebProcess/Storage/ServiceWorkerClientFetch.cpp:
(WebKit::ServiceWorkerClientFetch::didReceiveResponse):
(WebKit::ServiceWorkerClientFetch::didReceiveData):
(WebKit::ServiceWorkerClientFetch::didFinish):
(WebKit::ServiceWorkerClientFetch::didFail):
(WebKit::ServiceWorkerClientFetch::didNotHandle):

LayoutTests:

Unskip test that is no longer flaky.

* platform/mac-wk2/TestExpectations:

git-svn-id: https://svn.webkit.org/repository/webkit/trunk@228198 268f45cc-cd09-0410-ab3c-d52691b4dbfc
LayoutTests/ChangeLog
LayoutTests/platform/mac-wk2/TestExpectations
Source/WebKit/ChangeLog
Source/WebKit/WebProcess/Storage/ServiceWorkerClientFetch.cpp
Source/WebKit/WebProcess/Storage/ServiceWorkerClientFetch.h