Register a Service Worker when an extension is enabled.

Register a Service Worker when an extension is enabled.

The ServiceWorkerManager handles registration and deregistration requests from the ExtensionService and hands things off to the IO thread and ServiceWorkerContext. Eventually, this manager will also proxy messages and make sure they're only sent after the SW registration has taken effect.

BUG=347328

[Jeffrey Yasskin, 2014-03-08 04:35:37]

Hey Service Worker folks,

No reply needed until Monday, but I wanted to get this into your inboxes.

This is the beginning of an implementation of
https://docs.google.com/document/d/1szeOHrr_qEJGSNbDtEqeKcGDkLmwvftqTV731kQw2....
I have two questions so far:

1) What do you want the public content API to look like, roughly? You can see in
https://codereview.chromium.org/182253010/diff/20001/extensions/browser/servi...
and
https://codereview.chromium.org/182253010/diff/20001/chrome/browser/extension...
roughly the APIs that I'd like to call from the main code and the test. We're
also going to need to call ServiceWorkerVersion::SendMessage in a near-future
CL. If you can sketch the API you want in content/, I'll implement the subset
this CL needs.

2) Is the source_process_id the RenderProcessHost::GetID() for some extension
renderer that I need to create myself?

Thanks,
Jeffrey

[kinuko, 2014-03-10 07:03:18]

(Haven't really looked through all the code/docs yet)

> 1) What do you want the public content API to look like, roughly?

That'll depend on what APIs extension/apps will need to call :)
So far I could see extensions want to have: register (install), unregister
(uninstall), look-up registered SWs for a scope (just to verify registration for
testing, or more?), and send messages to/from a SW. It's unclear to me if more
internal access/information is needed in chrome/ C++ layer, e.g. if it needs
direct access to pending ServiceWorkerVersion.

> 2) Is the source_process_id the RenderProcessHost::GetID() for some extension
renderer that I need to create myself?

Is it right to assume that we're calling these (i.e. SW API, like
register/unregister) from a running extension context?  If so each extension
should have its corresponding RenderProcessHost (e.g. in an extension function
it can be accessed via render_view_host()->GetSiteInstance()->GetProcess()) and
you can just use it... but maybe my assumption is not correct? Current SW
implementation requires a renderer process to run a registration process, it'll
be the easiest to run it when an extension is instantiated and has started to
run.

https://codereview.chromium.org/182253010/diff/20001/extensions/browser/servi...
File extensions/browser/service_worker_manager.cc (right):

https://codereview.chromium.org/182253010/diff/20001/extensions/browser/servi...
extensions/browser/service_worker_manager.cc:93:
base::Bind(&RunCallback1<ServiceWorkerStatusCode>, continuation, status));
nit: why don't we just do base::Bind(continuation, status) ?

[scheib, 2014-03-10 21:31:38]

https://codereview.chromium.org/182253010/diff/20001/extensions/browser/servi...
File extensions/browser/service_worker_manager.cc (right):

https://codereview.chromium.org/182253010/diff/20001/extensions/browser/servi...
extensions/browser/service_worker_manager.cc:53:
DCHECK(BrowserThread::CurrentlyOn(thread)) << CurrentBrowserThreadName();
Maybe base::MessageLoop::current()->thread_name();

[michaeln, 2014-03-10 22:15:03]

1) What do you want the public content API to look like roughly?

I'd vote to have the public API be callable on the main thread and to have the
impl deal with task posting busywork and try to put all the methods you need on
the ServiceWorkerContext class. Probably we'll need to put a put public facing
ServiceWorker class in there too? So far looks like you need Register and
Unregister.

The process_id refers to the renderer process that's trying to register the
service worker. We try to start the service worker script in that process.
Usually we can attribute needing to start a worker back to an calling page. That
doesn't work for this usecase.

https://codereview.chromium.org/182253010/diff/20001/extensions/browser/servi...
File extensions/browser/service_worker_manager.cc (right):

https://codereview.chromium.org/182253010/diff/20001/extensions/browser/servi...
extensions/browser/service_worker_manager.cc:112: // that the callbacks come
back in the same order, and that the last one will be
That order is guaranteed for the same 'scope', but not for operations on
different registrations. The order in which foo.com and boo.com's registrations
complete may be different then the order in which they started.

Looks like that's what you mean from comment about the final state... just
checking.

[scheib, 2014-03-12 21:42:48]

https://codereview.chromium.org/182253010/diff/20001/chrome/browser/extension...
File chrome/browser/extensions/service_worker_browsertest.cc (right):

https://codereview.chromium.org/182253010/diff/20001/chrome/browser/extension...
chrome/browser/extensions/service_worker_browsertest.cc:97:
ext_dir_.WriteFile("service_worker.js", "");
You will need:
 FILE_PATH_LITERAL("service_worker.js")

[alecflett, 2014-03-13 22:47:02]

On 2014/03/10 22:15:03, michaeln wrote:
> 1) What do you want the public content API to look like roughly?
> 
> I'd vote to have the public API be callable on the main thread and to have the
> impl deal with task posting busywork and try to put all the methods you need
on
> the ServiceWorkerContext class. Probably we'll need to put a put public facing
> ServiceWorker class in there too? So far looks like you need Register and
> Unregister.
> 

FWIW, For devtools, I'm also going to need to something to enumerate the service
worker registrations, from the UI thread...

I like the idea of exposing as much as possible on a flat API surface though,
and along similar lines, I floated this idea to jeffrey:

// send message to the current active service worker
ServiceWorkerContext::SendMessage(const GURL& scope, const IPC::Message,
base::Callback<void(ServiceWorkerStatus)> response)

(or some other kind of message class, I'm not picky about that) and we can
introduce a status enum along the lines of "no such registration" or "no active
version"

I think we'll of course also need to expose the ability to send messages to a
specific ServiceWorkerVersion as well, I could see that looking like:

// send message to a specific ServiceWorkerVersion:
ServiceWorkerContext::SendMessage(const GURL& scope, int version_id, const
IPC::Message, base::Callback<void(ServiceWorkerStatus)> response)


> The process_id refers to the renderer process that's trying to register the
> service worker. We try to start the service worker script in that process.
> Usually we can attribute needing to start a worker back to an calling page.
That
> doesn't work for this usecase.
> 
>
https://codereview.chromium.org/182253010/diff/20001/extensions/browser/servi...
> File extensions/browser/service_worker_manager.cc (right):
> 
>
https://codereview.chromium.org/182253010/diff/20001/extensions/browser/servi...
> extensions/browser/service_worker_manager.cc:112: // that the callbacks come
> back in the same order, and that the last one will be
> That order is guaranteed for the same 'scope', but not for operations on
> different registrations. The order in which http://foo.com and boo.com's
registrations
> complete may be different then the order in which they started.
> 
> Looks like that's what you mean from comment about the final state... just
> checking.

[scheib, 2014-04-24 22:11:39]

https://codereview.chromium.org/182253010/diff/140001/extensions/browser/exte...
File extensions/browser/extension_host.h (right):

https://codereview.chromium.org/182253010/diff/140001/extensions/browser/exte...
extensions/browser/extension_host.h:50: ExtensionHost(const Extension*
extension,
Planning to keep the use of ExtensionHost for service worker backed extensions,
and having ExtensionHost abstract the details of being RenderView or
ServiceWorker backed?

https://codereview.chromium.org/182253010/diff/140001/extensions/browser/exte...
extensions/browser/extension_host.h:58: content::RenderViewHost*
render_view_host() const;
Extension with a ServiceWorker won't have a RenderViewHost to return here,
right? It would be appropriate to have something like ServiceWorkerHost*?