|
Lines 1-3
a/Source/WebCore/ChangeLog_sec1
|
|
|
1 |
2018-01-17 Chris Dumez <cdumez@apple.com> |
| 2 |
|
| 3 |
'fetch' event may be sent to a service worker before its state is set to 'activated' |
| 4 |
https://bugs.webkit.org/show_bug.cgi?id=181698 |
| 5 |
<rdar://problem/36554856> |
| 6 |
|
| 7 |
Reviewed by Youenn Fablet. |
| 8 |
|
| 9 |
'fetch' event may be sent to a service worker before its state is set to 'activated'. |
| 10 |
When the registration's active worker needs to intercept a load, and its state is 'activating', |
| 11 |
we queue the request to send the fetch event in SWServerWorker::m_whenActivatedHandlers. |
| 12 |
Once the SWServerWorker::setState() is called with 'activated' state, we then call the |
| 13 |
handlers in m_whenActivatedHandlers to make send the fetch event now that the worker is |
| 14 |
activated. The issue is that even though the worker is activated and its state was set to |
| 15 |
'activated' on Storage process side, we had not yet notified the ServiceWorker process |
| 16 |
of the service worker's new state yet. |
| 17 |
|
| 18 |
To address the issue, we now make sure that SWServerWorker::m_whenActivatedHandlers are |
| 19 |
called *after* we've sent the IPC to the ServiceWorker process to update the worker's |
| 20 |
state to 'activated'. Also, we now call ServiceWorkerFetch::dispatchFetchEvent() |
| 21 |
asynchronously in a postTask() as the service worker's state is also updated asynchronously |
| 22 |
in a postTask. This is as per specification [1], which says to "queue a task" to fire |
| 23 |
the fetch event. |
| 24 |
|
| 25 |
[1] https://w3c.github.io/ServiceWorker/#on-fetch-request-algorithm (step 18) |
| 26 |
|
| 27 |
No new tests, covered by imported/w3c/web-platform-tests/service-workers/service-worker/fetch-waits-for-activate.https.html |
| 28 |
which hits the new assertion without the fix. |
| 29 |
|
| 30 |
* workers/service/context/ServiceWorkerFetch.cpp: |
| 31 |
(WebCore::ServiceWorkerFetch::dispatchFetchEvent): |
| 32 |
Add assertions to make sure that we dispatch the fetch event on the right worker and |
| 33 |
that the worker is in 'activated' state. |
| 34 |
|
| 35 |
* workers/service/context/ServiceWorkerThread.cpp: |
| 36 |
(WebCore::ServiceWorkerThread::postFetchTask): |
| 37 |
Queue a task to fire the fetch event as per: |
| 38 |
- https://w3c.github.io/ServiceWorker/#on-fetch-request-algorithm (step 18) |
| 39 |
We need to match the specification exactly here or things will happen in the wrong |
| 40 |
order. In particular, things like "update registration state" and "update worker state" |
| 41 |
might happen *after* firing the fetch event, even though the IPC for "update registration/worker |
| 42 |
state" was sent before the "fire fetch event" one, because the code for updating a registration/ |
| 43 |
worker state already queues a task, as per the specification. |
| 44 |
|
| 45 |
* workers/service/server/SWServerRegistration.cpp: |
| 46 |
(WebCore::SWServerRegistration::updateWorkerState): |
| 47 |
* workers/service/server/SWServerRegistration.h: |
| 48 |
* workers/service/server/SWServerWorker.cpp: |
| 49 |
(WebCore::SWServerWorker::setState): |
| 50 |
Move code to send the IPC to the Service Worker process whenever the service worker's state |
| 51 |
needs to be updated from SWServerRegistration::updateWorkerState() to SWServerWorker::setState(). |
| 52 |
This way, we can make sure the IPC is sent *before* we call the m_whenActivatedHandlers handlers, |
| 53 |
as they may also send IPC to the Service Worker process, and we need to make sure this IPC happens |
| 54 |
after so that the service worker is in the right state. |
| 55 |
|
| 1 |
2018-01-17 Zan Dobersek <zdobersek@igalia.com> |
56 |
2018-01-17 Zan Dobersek <zdobersek@igalia.com> |
| 2 |
|
57 |
|
| 3 |
Unreviewed follow-up to r227051. |
58 |
Unreviewed follow-up to r227051. |