Bug 180261 - Implement https://w3c.github.io/ServiceWorker/#clients-claim
Summary: Implement https://w3c.github.io/ServiceWorker/#clients-claim
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebCore Misc. (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: youenn fablet
URL:
Keywords: InRadar
Depends on: 180382
Blocks:
  Show dependency treegraph
 
Reported: 2017-12-01 10:22 PST by youenn fablet
Modified: 2017-12-06 10:27 PST (History)
8 users (show)

See Also:


Attachments
Patch (47.30 KB, patch)
2017-12-01 10:37 PST, youenn fablet
no flags Details | Formatted Diff | Diff
Patch (34.79 KB, patch)
2017-12-04 11:25 PST, youenn fablet
no flags Details | Formatted Diff | Diff
Patch (31.27 KB, patch)
2017-12-05 10:58 PST, youenn fablet
no flags Details | Formatted Diff | Diff
Patch for landing (31.51 KB, patch)
2017-12-05 12:47 PST, youenn fablet
no flags Details | Formatted Diff | Diff
Rebasing (31.45 KB, patch)
2017-12-05 13:26 PST, youenn fablet
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description youenn fablet 2017-12-01 10:22:45 PST
Implement https://w3c.github.io/ServiceWorker/#clients-claim
Comment 1 youenn fablet 2017-12-01 10:37:13 PST
Created attachment 328118 [details]
Patch
Comment 2 youenn fablet 2017-12-04 11:25:57 PST
Created attachment 328365 [details]
Patch
Comment 3 Chris Dumez 2017-12-04 12:48:00 PST
Comment on attachment 328365 [details]
Patch

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

> Source/WebCore/ChangeLog:10
> +        Update setting active service woker within ScriptExecutionContext to not do any notification to the storage process.

typo: woker

> Source/WebCore/workers/service/SWClientConnection.cpp:222
> +        client->setActiveServiceWorker(ServiceWorker::getOrCreate(*client, ServiceWorkerData { newController }), ScriptExecutionContext::ShouldNotifyServiceWorkerConnection::No);

notifyClientsOfControllerChange() is also called from activate() for example. How does the server know the client's new controlling worker if you use ShouldNotifyServiceWorkerConnection::No here?

> Source/WebCore/workers/service/server/SWServer.cpp:371
> +            auto controllingRegistration = m_registrations.get(m_runningOrTerminatingWorkers.get(result.iterator->value)->registrationKey());

The spec says to call "Handle Service Worker Client Unload". Where do you do this?
Comment 4 youenn fablet 2017-12-04 13:11:37 PST
> > Source/WebCore/workers/service/SWClientConnection.cpp:222
> > +        client->setActiveServiceWorker(ServiceWorker::getOrCreate(*client, ServiceWorkerData { newController }), ScriptExecutionContext::ShouldNotifyServiceWorkerConnection::No);
> 
> notifyClientsOfControllerChange() is also called from activate() for
> example. How does the server know the client's new controlling worker if you
> use ShouldNotifyServiceWorkerConnection::No here?

I see, it is used for that purpose as well.
I think SWServer should set it in StorageProcess without having to wait for WebProcess to set it on its client.
 
> > Source/WebCore/workers/service/server/SWServer.cpp:371
> > +            auto controllingRegistration = m_registrations.get(m_runningOrTerminatingWorkers.get(result.iterator->value)->registrationKey());
> 
> The spec says to call "Handle Service Worker Client Unload". Where do you do
> this?

In the line just after, when removing client from registration.
Comment 5 Chris Dumez 2017-12-04 13:13:26 PST
(In reply to youenn fablet from comment #4)
> > > Source/WebCore/workers/service/SWClientConnection.cpp:222
> > > +        client->setActiveServiceWorker(ServiceWorker::getOrCreate(*client, ServiceWorkerData { newController }), ScriptExecutionContext::ShouldNotifyServiceWorkerConnection::No);
> > 
> > notifyClientsOfControllerChange() is also called from activate() for
> > example. How does the server know the client's new controlling worker if you
> > use ShouldNotifyServiceWorkerConnection::No here?
> 
> I see, it is used for that purpose as well.
> I think SWServer should set it in StorageProcess without having to wait for
> WebProcess to set it on its client.

Sure, but I do not think it is done currently so the patch would regress things.

>  
> > > Source/WebCore/workers/service/server/SWServer.cpp:371
> > > +            auto controllingRegistration = m_registrations.get(m_runningOrTerminatingWorkers.get(result.iterator->value)->registrationKey());
> > 
> > The spec says to call "Handle Service Worker Client Unload". Where do you do
> > this?
> 
> In the line just after, when removing client from registration.

Actually, client unload should do these too:
If registration’s uninstalling flag is set, invoke Try Clear Registration with registration.
If registration is not null, invoke Try Activate with registration.
Comment 6 youenn fablet 2017-12-05 10:58:43 PST
Created attachment 328470 [details]
Patch
Comment 7 Chris Dumez 2017-12-05 12:20:24 PST
Comment on attachment 328470 [details]
Patch

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

r=me

> Source/WebCore/workers/service/server/SWServerWorker.cpp:142
> +    auto* registration = m_server.getRegistration(m_registrationKey);

I think a comment pointing the which part of which algorithm is implemented would be helpful here.

> LayoutTests/http/tests/workers/service/serviceworkerclients-claim-worker.js:2
> +    if (event.request.url.indexOf("pinkelephant") !== -1)

lol
Comment 8 youenn fablet 2017-12-05 12:47:29 PST
Created attachment 328487 [details]
Patch for landing
Comment 9 youenn fablet 2017-12-05 12:48:23 PST
Thanks for the review.

> > Source/WebCore/workers/service/server/SWServerWorker.cpp:142
> > +    auto* registration = m_server.getRegistration(m_registrationKey);
> 
> I think a comment pointing the which part of which algorithm is implemented
> would be helpful here.

Done
Comment 10 WebKit Commit Bot 2017-12-05 13:20:30 PST
Comment on attachment 328487 [details]
Patch for landing

Rejecting attachment 328487 [details] from commit-queue.

Failed to run "['/Volumes/Data/EWS/WebKit/Tools/Scripts/webkit-patch', '--status-host=webkit-queues.webkit.org', '--bot-id=webkit-cq-03', 'land-attachment', '--force-clean', '--non-interactive', '--parent-command=commit-queue', 328487, '--port=mac']" exit_code: 2 cwd: /Volumes/Data/EWS/WebKit

Last 500 characters of output:
.webkit.org/git/WebKit
   6a810d9..9772276  master     -> origin/master
Partial-rebuilding .git/svn/refs/remotes/origin/master/.rev_map.268f45cc-cd09-0410-ab3c-d52691b4dbfc ...
Currently at 225530 = 6a810d93379060e6a3c4a9b02a287328d9de8c19
r225531 = 977227696fd292541c136dc33a2194e3c3116f3c
Done rebuilding .git/svn/refs/remotes/origin/master/.rev_map.268f45cc-cd09-0410-ab3c-d52691b4dbfc
First, rewinding head to replay your work on top of it...
Fast-forwarded master to refs/remotes/origin/master.

Full output: http://webkit-queues.webkit.org/results/5505205
Comment 11 youenn fablet 2017-12-05 13:26:31 PST
Created attachment 328490 [details]
Rebasing
Comment 12 WebKit Commit Bot 2017-12-05 13:51:46 PST
Comment on attachment 328490 [details]
Rebasing

Clearing flags on attachment: 328490

Committed r225537: <https://trac.webkit.org/changeset/225537>
Comment 13 WebKit Commit Bot 2017-12-05 13:51:47 PST
All reviewed patches have been landed.  Closing bug.
Comment 14 Radar WebKit Bug Importer 2017-12-05 13:53:19 PST
<rdar://problem/35863924>