Identify service worker version at main resource load time.

Identify sw version at main resource load time.
The corresponding blink change is blink r169479.

BUG=285976
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=260672

[michaeln, 2014-03-11 02:17:28]

Not ready yet but heads up. I also need to prep the blnk side to invoke the new
createDataSource method.

[michaeln, 2014-03-11 02:24:03]

https://codereview.chromium.org/193723003/diff/10001/content/renderer/service...
File content/renderer/service_worker/embedded_worker_context_client.cc (right):

https://codereview.chromium.org/193723003/diff/10001/content/renderer/service...
content/renderer/service_worker/embedded_worker_context_client.cc:72:
ServiceWorkerNetworkProvider::FromDocumentState(
We'll need to construct the provider here, not just look it up.

[michaeln, 2014-03-11 02:37:05]

Here's the fledgling blink side
https://codereview.chromium.org/194073002/

I have to similarly have to add a willSendRequest() plumbing so we can annotate
requests with the id.

[kinuko, 2014-03-11 09:16:45]

Nice, thanks for plumbing this too!

[michaeln, 2014-03-12 01:28:08]

i don't have new snapshots for this just yet, but i'm getting there

[michaeln, 2014-03-14 00:56:58]

Finally got some new snapshots to look at.

https://codereview.chromium.org/193723003/diff/30001/content/renderer/service...
File content/renderer/service_worker/embedded_worker_context_client.cc (right):

https://codereview.chromium.org/193723003/diff/30001/content/renderer/service...
content/renderer/service_worker/embedded_worker_context_client.cc:61: : public
blink::WebServiceWorkerNetworkProvider {
Had to introduce a new object for use on the main thread because
WebServiceWorkerContextClient is handed off to the background which owns it.

[kinuko, 2014-03-14 11:46:44]

I see... looking good.

https://codereview.chromium.org/193723003/diff/30001/content/child/request_ex...
File content/child/request_extra_data.h (right):

https://codereview.chromium.org/193723003/diff/30001/content/child/request_ex...
content/child/request_extra_data.h:23: RequestExtraData(int
service_worker_provider_id);
nit: explicit ?

https://codereview.chromium.org/193723003/diff/30001/content/child/service_wo...
File content/child/service_worker/service_worker_network_provider.cc (right):

https://codereview.chromium.org/193723003/diff/30001/content/child/service_wo...
content/child/service_worker/service_worker_network_provider.cc:58: // todo: add
new message type and handler in backend
(I assume you'll make it a proper TODO comment or will implement it in this CL)

https://codereview.chromium.org/193723003/diff/30001/content/renderer/service...
File content/renderer/service_worker/embedded_worker_context_client.cc (right):

https://codereview.chromium.org/193723003/diff/30001/content/renderer/service...
content/renderer/service_worker/embedded_worker_context_client.cc:55: static
DataSourceExtraData* FromDataSource(blink::WebDataSource* ds) {
Um... this is probably not necessary?

https://codereview.chromium.org/193723003/diff/30001/content/renderer/service...
content/renderer/service_worker/embedded_worker_context_client.cc:61: : public
blink::WebServiceWorkerNetworkProvider {
On 2014/03/14 00:56:58, michaeln wrote:
> Had to introduce a new object for use on the main thread because
> WebServiceWorkerContextClient is handed off to the background which owns it.

Got it... can you add a brief class comment to note that who owns this?

https://codereview.chromium.org/193723003/diff/30001/content/renderer/service...
content/renderer/service_worker/embedded_worker_context_client.cc:95:
g_worker_client_tls.Pointer()->Set(this);
Oops... can we just delete this line? We seem to reset the tls value at line 137

[michaeln, 2014-03-15 01:19:26]

https://codereview.chromium.org/193723003/diff/30001/content/child/request_ex...
File content/child/request_extra_data.h (right):

https://codereview.chromium.org/193723003/diff/30001/content/child/request_ex...
content/child/request_extra_data.h:23: RequestExtraData(int
service_worker_provider_id);
On 2014/03/14 11:46:44, kinuko wrote:
> nit: explicit ?

Done.

https://codereview.chromium.org/193723003/diff/30001/content/child/service_wo...
File content/child/service_worker/service_worker_network_provider.cc (right):

https://codereview.chromium.org/193723003/diff/30001/content/child/service_wo...
content/child/service_worker/service_worker_network_provider.cc:58: // todo: add
new message type and handler in backend
On 2014/03/14 11:46:44, kinuko wrote:
> (I assume you'll make it a proper TODO comment or will implement it in this
CL)

Done (added the message, will add the remote side in a seperate cl)

https://codereview.chromium.org/193723003/diff/30001/content/renderer/service...
File content/renderer/service_worker/embedded_worker_context_client.cc (right):

https://codereview.chromium.org/193723003/diff/30001/content/renderer/service...
content/renderer/service_worker/embedded_worker_context_client.cc:55: static
DataSourceExtraData* FromDataSource(blink::WebDataSource* ds) {
On 2014/03/14 11:46:44, kinuko wrote:
> Um... this is probably not necessary?

Done.

https://codereview.chromium.org/193723003/diff/30001/content/renderer/service...
content/renderer/service_worker/embedded_worker_context_client.cc:61: : public
blink::WebServiceWorkerNetworkProvider {
On 2014/03/14 11:46:44, kinuko wrote:
> On 2014/03/14 00:56:58, michaeln wrote:
> > Had to introduce a new object for use on the main thread because
> > WebServiceWorkerContextClient is handed off to the background which owns it.
> 
> Got it... can you add a brief class comment to note that who owns this?

Done.

https://codereview.chromium.org/193723003/diff/30001/content/renderer/service...
content/renderer/service_worker/embedded_worker_context_client.cc:95:
g_worker_client_tls.Pointer()->Set(this);
On 2014/03/14 11:46:44, kinuko wrote:
> Oops... can we just delete this line? We seem to reset the tls value at line
137

Done.

[kinuko, 2014-03-17 05:21:45]

lgtm for service worker related changes

[michaeln, 2014-03-17 21:54:32]

Thnx kinuko, i need some other owner reviews too.

@jam for content\child stuff not in service-worker
@dchecg for the messages.h stuff

This (snapshot5) won't build yet until a blink change lands,
https://codereview.chromium.org/194073002/. I'll temporarily remove the compile
time dependency in snapshot #6 just so we can run tryjobs against the changes to
child/common stuff in advance of blink landing/rolling.

[dcheng, 2014-03-17 22:12:09]

Two other questions:
1) I don't see a message handler for ServiceWorkerHostMsg_SetVersionId. Am I
missing something really obvious?
2) What are different possible values for version ID and what do they affect?

https://codereview.chromium.org/193723003/diff/70001/content/child/request_ex...
File content/child/request_extra_data.h (right):

https://codereview.chromium.org/193723003/diff/70001/content/child/request_ex...
content/child/request_extra_data.h:23: explicit RequestExtraData(int
service_worker_provider_id);
I'm not a huge fan of the constructor from int, since there are a number of
other int fields and it's not particularly obvious to me that a constructor from
int "should" be a service worker provider id.

https://codereview.chromium.org/193723003/diff/70001/content/common/service_w...
File content/common/service_worker/service_worker_messages.h (right):

https://codereview.chromium.org/193723003/diff/70001/content/common/service_w...
content/common/service_worker/service_worker_messages.h:90: // Informs the
browser that |provider_id| is associated
The comment for this block of IPC messages is "Messages sent from the browser to
the child process.". But this seems to be a message from the child to the
browser?

https://codereview.chromium.org/193723003/diff/70001/content/renderer/service...
File content/renderer/service_worker/embedded_worker_context_client.cc (right):

https://codereview.chromium.org/193723003/diff/70001/content/renderer/service...
content/renderer/service_worker/embedded_worker_context_client.cc:196:
extra_data, provider.Pass());
Who gets ownership of |extra_data|?

[michaeln, 2014-03-17 22:53:58]

> 1) I don't see a message handler for ServiceWorkerHostMsg_SetVersionId. 
> 2) What are different possible values for version ID and what do they affect?

I haven't written the handler for it yet. It's an int64 value that uniquely
identifies a particular version of a service worker registration within a
particular storage partition. This CL is just one small change towards fleshing
out an as yet unimplemented design.

This id value lets the ServiceWorkerProviderHost find the ServiceWorkerVersion
it's a host for. This is a different relationship then that of Documents (they
have a provider host too) being associated with a Version. The id will be used
to identify the correct ScriptCache from which to read the workers script
resources (or write them if this is the first invocation the worker). But lot's
of other code needs to be written before that can happen.

Probably not much of that made sense, but that's ok because kinuko has that
covered.

https://codereview.chromium.org/193723003/diff/70001/content/child/request_ex...
File content/child/request_extra_data.h (right):

https://codereview.chromium.org/193723003/diff/70001/content/child/request_ex...
content/child/request_extra_data.h:23: explicit RequestExtraData(int
service_worker_provider_id);
I'd chose this instead of a public setter for just that single data member. I'd
be fine with changing this around to cons up a RequestExtraData struct with just
that one field set differently then the defaults. Did you have anything
particular in mind?

https://codereview.chromium.org/193723003/diff/70001/content/common/service_w...
File content/common/service_worker/service_worker_messages.h (right):

https://codereview.chromium.org/193723003/diff/70001/content/common/service_w...
content/common/service_worker/service_worker_messages.h:90: // Informs the
browser that |provider_id| is associated
On 2014/03/17 22:12:10, dcheng wrote:
> The comment for this block of IPC messages is "Messages sent from the browser
to
> the child process.". But this seems to be a message from the child to the
> browser?

You're right, a bunch of them (most i think) are in the wrong section, i'll move
them.

https://codereview.chromium.org/193723003/diff/70001/content/renderer/service...
File content/renderer/service_worker/embedded_worker_context_client.cc (right):

https://codereview.chromium.org/193723003/diff/70001/content/renderer/service...
content/renderer/service_worker/embedded_worker_context_client.cc:196:
extra_data, provider.Pass());
On 2014/03/17 22:12:10, dcheng wrote:
> Who gets ownership of |extra_data|?

It's in the code comment.
// and ownership is transferred to the DataSource.

[michaeln, 2014-03-17 23:04:37]

Both of the id values in the new message are sequence numbers and not derived
from content (like a routeID).

[michaeln, 2014-03-17 23:27:03]

https://codereview.chromium.org/193723003/diff/70001/content/common/service_w...
File content/common/service_worker/service_worker_messages.h (right):

https://codereview.chromium.org/193723003/diff/70001/content/common/service_w...
content/common/service_worker/service_worker_messages.h:90: // Informs the
browser that |provider_id| is associated
On 2014/03/17 22:53:58, michaeln wrote:
> On 2014/03/17 22:12:10, dcheng wrote:
> > The comment for this block of IPC messages is "Messages sent from the
browser
> to
> > the child process.". But this seems to be a message from the child to the
> > browser?
> 
> You're right, a bunch of them (most i think) are in the wrong section, i'll
move
> them.

Done.

[dcheng, 2014-03-18 04:05:49]

On 2014/03/17 22:53:58, michaeln wrote:
> > 1) I don't see a message handler for ServiceWorkerHostMsg_SetVersionId. 
> > 2) What are different possible values for version ID and what do they
affect?
> 
> I haven't written the handler for it yet. It's an int64 value that uniquely
> identifies a particular version of a service worker registration within a
> particular storage partition. This CL is just one small change towards
fleshing
> out an as yet unimplemented design.
> 
> This id value lets the ServiceWorkerProviderHost find the ServiceWorkerVersion
> it's a host for. This is a different relationship then that of Documents (they
> have a provider host too) being associated with a Version. The id will be used
> to identify the correct ScriptCache from which to read the workers script
> resources (or write them if this is the first invocation the worker). But
lot's
> of other code needs to be written before that can happen.
> 
> Probably not much of that made sense, but that's ok because kinuko has that
> covered.

What happens if a service worker forges a version ID? Could it access the
ScriptCache for another worker?

https://codereview.chromium.org/193723003/diff/70001/content/renderer/service...
File content/renderer/service_worker/embedded_worker_context_client.cc (right):

https://codereview.chromium.org/193723003/diff/70001/content/renderer/service...
content/renderer/service_worker/embedded_worker_context_client.cc:196:
extra_data, provider.Pass());
On 2014/03/17 22:53:58, michaeln wrote:
> On 2014/03/17 22:12:10, dcheng wrote:
> > Who gets ownership of |extra_data|?
> 
> It's in the code comment.
> // and ownership is transferred to the DataSource.

The comment sounds like it's referring to the provider that was created on line
185 though. But I missed a line earlier--I think data_source->setExtraData()
actually takes ownership of it.

[jam, 2014-03-18 18:18:55]

On 2014/03/17 21:54:32, michaeln wrote:
> Thnx kinuko, i need some other owner reviews too.
> 
> @jam for content\child stuff not in service-worker
> @dchecg for the messages.h stuff
> 
> This (snapshot5) won't build yet until a blink change lands,
> https://codereview.chromium.org/194073002/. I'll temporarily remove the
compile
> time dependency in snapshot #6 just so we can run tryjobs against the changes
to
> child/common stuff in advance of blink landing/rolling.

https://codereview.chromium.org/182383015 removes the constructor with
parameters and makes it so that only an empty constructor is used and each
member is set individually. it seems it would make this code clearer as well.
can you wait for that to land?

[michaeln, 2014-03-18 20:04:43]

> https://codereview.chromium.org/182383015 removes the constructor with
> parameters and makes it so that only an empty constructor is used and each
> member is set individually. it seems it would make this code clearer as well.
> can you wait for that to land?

You bet, but I'm surprised to see the default ctor does not initialize the
memebers to default values? Part of my concern was sharing the code that sets up
the initial values for this set of params so different callsites wouldn't get
out of sync with one another.

Haven't look closely at the change yet, but is there a helper method to set all
fields to default values?

[michaeln, 2014-03-18 20:46:54]

> What happens if a service worker forges a version ID? Could it access the
> ScriptCache for another worker?

Service workers do not produce these ids so they can't forge them. Maybe you're
asking about a compromised renderer, which is a good question and makes me think
of what the msg handler should look at for bad message detection.

> Could it access the ScriptCache for another worker?

I don't think so. We have a couple layers of defense.
1st layer of defense, upon receipt of this message, we can apply some pretty
good checks against things that are not in the renderers control.
* The browser process decides which renderer process to start service workers
in, if this message is from another process... bad message.
* The version has to be in a very transient state where it's in the STARTING
state, if that's not the case... its a bad message.

2nd layer of defense.
Setting of this value does nothing on its own. To access the script cache the
compromised renderer would have to send ResourceHostMsg_Request ipcs which have
another set of integrity checks.


> > // and ownership is transferred to the DataSource.
> 
> The comment sounds like it's referring to the provider that was created on
line
> 185 though. But I missed a line earlier--I think data_source->setExtraData()
> actually takes ownership of it.

Yes, ownership of both are xfer'd to the DataSource.

[jam, 2014-03-19 16:45:57]

On 2014/03/18 20:04:43, michaeln wrote:
> > https://codereview.chromium.org/182383015 removes the constructor with
> > parameters and makes it so that only an empty constructor is used and each
> > member is set individually. it seems it would make this code clearer as
well.
> > can you wait for that to land?
> 
> You bet, but I'm surprised to see the default ctor does not initialize the
> memebers to default values? Part of my concern was sharing the code that sets
up
> the initial values for this set of params so different callsites wouldn't get
> out of sync with one another.

Yep completely agree :)

> 
> Haven't look closely at the change yet, but is there a helper method to set
all
> fields to default values?

I think it was an oversight that the constructor didn't do that. It should be
done before the change is relanded.

[michaeln, 2014-03-19 22:09:39]

@dcheng, friendly ping

@jam, i haven't looked to see where https://codereview.chromium.org/182383015
stands right now but assuming its there and this is rebased/merged without,any
other comments?

[dcheng, 2014-03-19 22:13:26]

On 2014/03/18 20:46:54, michaeln wrote:
> > What happens if a service worker forges a version ID? Could it access the
> > ScriptCache for another worker?
> 
> Service workers do not produce these ids so they can't forge them. Maybe
you're
> asking about a compromised renderer, which is a good question and makes me
think
> of what the msg handler should look at for bad message detection.
> 
> > Could it access the ScriptCache for another worker?
> 
> I don't think so. We have a couple layers of defense.
> 1st layer of defense, upon receipt of this message, we can apply some pretty
> good checks against things that are not in the renderers control.
> * The browser process decides which renderer process to start service workers
> in, if this message is from another process... bad message.
> * The version has to be in a very transient state where it's in the STARTING
> state, if that's not the case... its a bad message.
> 
> 2nd layer of defense.
> Setting of this value does nothing on its own. To access the script cache the
> compromised renderer would have to send ResourceHostMsg_Request ipcs which
have
> another set of integrity checks.
> 
> 
> > > // and ownership is transferred to the DataSource.
> > 
> > The comment sounds like it's referring to the provider that was created on
> line
> > 185 though. But I missed a line earlier--I think data_source->setExtraData()
> > actually takes ownership of it.
> 
> Yes, ownership of both are xfer'd to the DataSource.

Sorry, I was waiting for the rebase for RequestExtraData before taking a second
look. Yes, my question was in reference to a compromised renderer. The current
patch to *service_worker_messages.h LGTM, but we need to be careful how it gets
used in the future to make sure a compromised renderer can't sneakily elevate
its privileges.

[michaeln, 2014-03-19 22:29:08]

> Sorry, I was waiting for the rebase for RequestExtraData before taking a
second
> look. Yes, my question was in reference to a compromised renderer. The current
> patch to *service_worker_messages.h LGTM, but we need to be careful how it
gets
> used in the future to make sure a compromised renderer can't sneakily elevate
> its privileges.

thnx, i'll cc you when a handler that does more than NOTIMPLEMENTED() is put in
place

[michaeln, 2014-03-27 19:24:43]

@jam, ptal, rebased on top of https://codereview.chromium.org/182383015

[jam, 2014-03-27 22:59:17]

lgtm

https://codereview.chromium.org/193723003/diff/150001/content/child/resource_...
File content/child/resource_dispatcher.cc (left):

https://codereview.chromium.org/193723003/diff/150001/content/child/resource_...
content/child/resource_dispatcher.cc:152: request_.is_main_frame = false;
looks like before this would be set to false, but now the ctor of
RequestExtraData sets it to true. probably we want to fix the ctor of
RequestExtraData?

[jam, 2014-03-27 23:00:24]

https://codereview.chromium.org/193723003/diff/150001/content/child/request_e...
File content/child/request_extra_data.h (right):

https://codereview.chromium.org/193723003/diff/150001/content/child/request_e...
content/child/request_extra_data.h:17: // The RenderView and
EmbeddedWorkerContextClient store an instance of this
this is also set in pepper code. i think it's best to just make this comment not
say who sets it, since it doesn't matter. something like:

"Can be set by callers of ResourceDispatchers to store extra data on every
ResourceRequest...

[michaeln, 2014-03-27 23:09:00]

https://codereview.chromium.org/193723003/diff/150001/content/child/request_e...
File content/child/request_extra_data.h (right):

https://codereview.chromium.org/193723003/diff/150001/content/child/request_e...
content/child/request_extra_data.h:17: // The RenderView and
EmbeddedWorkerContextClient store an instance of this
On 2014/03/27 23:00:24, jam wrote:
> this is also set in pepper code. i think it's best to just make this comment
not
> say who sets it, since it doesn't matter. something like:
> 
> "Can be set by callers of ResourceDispatchers to store extra data on every
> ResourceRequest...

Done.

https://codereview.chromium.org/193723003/diff/150001/content/child/resource_...
File content/child/resource_dispatcher.cc (left):

https://codereview.chromium.org/193723003/diff/150001/content/child/resource_...
content/child/resource_dispatcher.cc:152: request_.is_main_frame = false;
Thank you for catching that.

[michaeln, 2014-03-27 23:21:52]

The CQ bit was checked by michaeln@chromium.org

[commit-bot: I haz the power, 2014-03-27 23:23:31]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/michaeln@chromium.org/193723003/170001

[cmp, 2014-03-30 16:28:38]

The CQ bit was unchecked by cmp@chromium.org

[cmp, 2014-03-30 16:32:00]

The CQ bit was checked by cmp@chromium.org

[commit-bot: I haz the power, 2014-03-30 16:32:20]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/michaeln@chromium.org/193723003/170001

[commit-bot: I haz the power, 2014-03-30 16:32:31]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-03-30 16:32:32]

Failed to apply patch for
content/common/service_worker/service_worker_messages.h:
While running patch -p1 --forward --force --no-backup-if-mismatch;
  patching file content/common/service_worker/service_worker_messages.h
  Hunk #1 succeeded at 59 (offset 4 lines).
  Hunk #2 FAILED at 127.
  1 out of 2 hunks FAILED -- saving rejects to file
content/common/service_worker/service_worker_messages.h.rej

Patch:       content/common/service_worker/service_worker_messages.h
Index: content/common/service_worker/service_worker_messages.h
diff --git a/content/common/service_worker/service_worker_messages.h
b/content/common/service_worker/service_worker_messages.h
index
c4af2717f2e3c8a3c08641a5fb6953717727df70..ea74be9985522ca9c38213abaef271d2de97a9fb
100644
--- a/content/common/service_worker/service_worker_messages.h
+++ b/content/common/service_worker/service_worker_messages.h
@@ -55,6 +55,43 @@ IPC_MESSAGE_CONTROL3(ServiceWorkerHostMsg_PostMessage,
                      base::string16 /* message */,
                      std::vector<int> /* sent_message_port_ids */)
 
+// Informs the browser of a new ServiceWorkerProvider in the child process,
+// |provider_id| is unique within its child process.
+IPC_MESSAGE_CONTROL1(ServiceWorkerHostMsg_ProviderCreated,
+                     int /* provider_id */)
+
+// Informs the browser of a ServiceWorkerProvider being destroyed.
+IPC_MESSAGE_CONTROL1(ServiceWorkerHostMsg_ProviderDestroyed,
+                     int /* provider_id */)
+
+// Informs the browser that |provider_id| is associated
+// with a service worker script running context and
+// |version_id| identifies which ServcieWorkerVersion.
+IPC_MESSAGE_CONTROL2(ServiceWorkerHostMsg_SetVersionId,
+                     int /* provider_id */,
+                     int64 /* version_id */)
+
+// Informs the browser of a new scriptable API client in the child process.
+IPC_MESSAGE_CONTROL2(ServiceWorkerHostMsg_AddScriptClient,
+                     int /* thread_id */,
+                     int /* provider_id */)
+
+// Informs the browser that the scriptable API client is unregistered.
+IPC_MESSAGE_CONTROL2(ServiceWorkerHostMsg_RemoveScriptClient,
+                     int /* thread_id */,
+                     int /* provider_id */)
+
+// Informs the browser that install event handling has finished.
+// Sent via EmbeddedWorker. If there was an exception during the
+// event handling it'll be reported back separately (to be propagated
+// to the documents).
+IPC_MESSAGE_CONTROL0(ServiceWorkerHostMsg_InstallEventFinished)
+
+// Informs the browser that fetch event handling has finished.
+IPC_MESSAGE_CONTROL2(ServiceWorkerHostMsg_FetchEventFinished,
+                     content::ServiceWorkerFetchEventResult,
+                     content::ServiceWorkerResponse)
+
 // Messages sent from the browser to the child process.
 
 // Response to ServiceWorkerMsg_RegisterServiceWorker
@@ -90,32 +127,3 @@ IPC_MESSAGE_CONTROL3(ServiceWorkerMsg_Message,
                      std::vector<int> /* sent_message_port_ids */,
                      std::vector<int> /* new_routing_ids */)
 
-// Informs the browser of a new ServiceWorkerProvider in the child process,
-// |provider_id| is unique within its child process.
-IPC_MESSAGE_CONTROL1(ServiceWorkerHostMsg_ProviderCreated,
-                     int /* provider_id */)
-
-// Informs the browser of a ServiceWorkerProvider being destroyed.
-IPC_MESSAGE_CONTROL1(ServiceWorkerHostMsg_ProviderDestroyed,
-                     int /* provider_id */)
-
-// Informs the browser of a new scriptable API client in the child process.
-IPC_MESSAGE_CONTROL2(ServiceWorkerHostMsg_AddScriptClient,
-                     int /* thread_id */,
-                     int /* provider_id */)
-
-// Informs the browser that the scriptable API client is unregistered.
-IPC_MESSAGE_CONTROL2(ServiceWorkerHostMsg_RemoveScriptClient,
-                     int /* thread_id */,
-                     int /* provider_id */)
-
-// Informs the browser that install event handling has finished.
-// Sent via EmbeddedWorker. If there was an exception during the
-// event handling it'll be reported back separately (to be propagated
-// to the documents).
-IPC_MESSAGE_CONTROL0(ServiceWorkerHostMsg_InstallEventFinished)
-
-// Informs the browser that fetch event handling has finished.
-IPC_MESSAGE_CONTROL2(ServiceWorkerHostMsg_FetchEventFinished,
-                     content::ServiceWorkerFetchEventResult,
-                     content::ServiceWorkerResponse)

[michaeln, 2014-03-31 19:24:05]

The CQ bit was checked by michaeln@chromium.org

[commit-bot: I haz the power, 2014-03-31 19:24:51]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/michaeln@chromium.org/193723003/190001

[commit-bot: I haz the power, 2014-03-31 22:17:33]

Change committed as 260672