Support dispatching ServiceWorker FetchEvent and receiving response

Support dispatching ServiceWorker FetchEvent and receiving response

Depends on Blink-change https://codereview.chromium.org/185423005/

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

[falken, 2014-03-03 06:00:50]

This depends on Blink change
https://codereview.chromium.org/185423005/

[kinuko, 2014-03-04 06:39:17]

looks good, some comments

https://codereview.chromium.org/178343011/diff/20001/content/browser/service_...
File content/browser/service_worker/service_worker_browsertest.cc (right):

https://codereview.chromium.org/178343011/diff/20001/content/browser/service_...
content/browser/service_worker/service_worker_browsertest.cc:53:
ServiceWorkerResponse response;
nit: 2 space indent

https://codereview.chromium.org/178343011/diff/20001/content/browser/service_...
File content/browser/service_worker/service_worker_version.cc (right):

https://codereview.chromium.org/178343011/diff/20001/content/browser/service_...
content/browser/service_worker/service_worker_version.cc:87:
ServiceWorkerHostMsg_FetchEventFinished::Read(&message, &params);
I think for 2+ parameters you can probably do this:

ServiceWorkerFetchEventResult result;
ServiceWorkerResponse response;
ServiceWorkerHostMsg_FetchEventFinished::Read(&message, &result, &response);

https://codereview.chromium.org/178343011/diff/20001/content/common/service_w...
File content/common/service_worker/service_worker_types.cc (right):

https://codereview.chromium.org/178343011/diff/20001/content/common/service_w...
content/common/service_worker/service_worker_types.cc:24:
ServiceWorkerResponse::ServiceWorkerResponse(
(I guess this part may change if we're directly going to expose this to blink
via public/platform)

https://codereview.chromium.org/178343011/diff/20001/content/common/service_w...
File content/common/service_worker/service_worker_types.h (right):

https://codereview.chromium.org/178343011/diff/20001/content/common/service_w...
content/common/service_worker/service_worker_types.h:47: RESPONSE
We're in a relatively big namespace, content, it'd be nicer to name these enums
with prefix.  E.g.
 SERVICE_WORKER_FETCH_RESULT_FALLBACK,
 SERVICE_WORKER_FETCH_RESULT_USE_RESPONSE

[falken, 2014-03-05 03:35:40]

Thanks! PTAL

https://codereview.chromium.org/178343011/diff/20001/content/browser/service_...
File content/browser/service_worker/service_worker_browsertest.cc (right):

https://codereview.chromium.org/178343011/diff/20001/content/browser/service_...
content/browser/service_worker/service_worker_browsertest.cc:53:
ServiceWorkerResponse response;
On 2014/03/04 06:39:17, kinuko wrote:
> nit: 2 space indent

Done. I also ran git-cl format and it made several other improvements.

https://codereview.chromium.org/178343011/diff/20001/content/browser/service_...
File content/browser/service_worker/service_worker_version.cc (right):

https://codereview.chromium.org/178343011/diff/20001/content/browser/service_...
content/browser/service_worker/service_worker_version.cc:87:
ServiceWorkerHostMsg_FetchEventFinished::Read(&message, &params);
On 2014/03/04 06:39:17, kinuko wrote:
> I think for 2+ parameters you can probably do this:
> 
> ServiceWorkerFetchEventResult result;
> ServiceWorkerResponse response;
> ServiceWorkerHostMsg_FetchEventFinished::Read(&message, &result, &response);

Done.

https://codereview.chromium.org/178343011/diff/20001/content/common/service_w...
File content/common/service_worker/service_worker_types.cc (right):

https://codereview.chromium.org/178343011/diff/20001/content/common/service_w...
content/common/service_worker/service_worker_types.cc:24:
ServiceWorkerResponse::ServiceWorkerResponse(
On 2014/03/04 06:39:17, kinuko wrote:
> (I guess this part may change if we're directly going to expose this to blink
> via public/platform)

Although WebServiceWorkerResponse is now in public/platform, we still need this
struct for the IPC message, no?

https://codereview.chromium.org/178343011/diff/20001/content/common/service_w...
File content/common/service_worker/service_worker_types.h (right):

https://codereview.chromium.org/178343011/diff/20001/content/common/service_w...
content/common/service_worker/service_worker_types.h:47: RESPONSE
On 2014/03/04 06:39:17, kinuko wrote:
> We're in a relatively big namespace, content, it'd be nicer to name these
enums
> with prefix.  E.g.
>  SERVICE_WORKER_FETCH_RESULT_FALLBACK,
>  SERVICE_WORKER_FETCH_RESULT_USE_RESPONSE

Done.

[kinuko, 2014-03-05 04:01:29]

lgtm

https://codereview.chromium.org/178343011/diff/20001/content/common/service_w...
File content/common/service_worker/service_worker_types.cc (right):

https://codereview.chromium.org/178343011/diff/20001/content/common/service_w...
content/common/service_worker/service_worker_types.cc:24:
ServiceWorkerResponse::ServiceWorkerResponse(
On 2014/03/05 03:35:41, falken wrote:
> On 2014/03/04 06:39:17, kinuko wrote:
> > (I guess this part may change if we're directly going to expose this to
blink
> > via public/platform)
> 
> Although WebServiceWorkerResponse is now in public/platform, we still need
this
> struct for the IPC message, no?

Right, nvm

https://codereview.chromium.org/178343011/diff/40001/content/common/service_w...
File content/common/service_worker/service_worker_types.h (right):

https://codereview.chromium.org/178343011/diff/40001/content/common/service_w...
content/common/service_worker/service_worker_types.h:32: struct CONTENT_EXPORT
ServiceWorkerFetchRequest {
We'll probably want drop 'Fetch' from this.. but it can be done in another patch

https://codereview.chromium.org/178343011/diff/40001/content/common/service_w...
content/common/service_worker/service_worker_types.h:56:
ServiceWorkerResponse(const blink::WebServiceWorkerResponse& response);
nit: explicit

https://codereview.chromium.org/178343011/diff/40001/content/test/data/servic...
File content/test/data/service_worker/fetch_event.js (right):

https://codereview.chromium.org/178343011/diff/40001/content/test/data/servic...
content/test/data/service_worker/fetch_event.js:13: }
(not related to this cl) if we want to do some demo without cache etc we'll
probably need a way to set blob etc to the response object... at some point we
may want to file an issue on github

https://codereview.chromium.org/178343011/diff/40001/content/test/data/servic...
File content/test/data/service_worker/fetch_event_error.js (right):

https://codereview.chromium.org/178343011/diff/40001/content/test/data/servic...
content/test/data/service_worker/fetch_event_error.js:10: 
nit: this empty line is not necessary?

[falken, 2014-03-05 04:27:44]

Thanks! Sorry, I accidentally deleted that patchset, so comments below:

>
https://codereview.chromium.org/178343011/diff/40001/content/common/service_w...
> content/common/service_worker/service_worker_types.h:56:
> ServiceWorkerResponse(const blink::WebServiceWorkerResponse& response);
> nit: explicit

Done

>
https://codereview.chromium.org/178343011/diff/40001/content/test/data/servic...
> content/test/data/service_worker/fetch_event_error.js:10: 
> nit: this empty line is not necessary?

Done

[falken, 2014-03-05 04:30:10]

tsepez: Can you please give OWNER review for IPC?
creis: Can you please give OWNER review for content/?

[Tom Sepez, 2014-03-05 19:45:02]

LGTM with comments.

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

https://codereview.chromium.org/178343011/diff/60001/content/common/service_w...
content/common/service_worker/service_worker_messages.h:29:
IPC_ENUM_TRAITS(content::ServiceWorkerFetchEventResult)
use IPC_ENUM_TRAITS_MAX_VALUE(content::ServiceWorkerFetchEventResult,
SERVICE_WORKER_FETCH_EVENT_RESULT_LAST)

https://codereview.chromium.org/178343011/diff/60001/content/common/service_w...
File content/common/service_worker/service_worker_types.h (right):

https://codereview.chromium.org/178343011/diff/60001/content/common/service_w...
content/common/service_worker/service_worker_types.h:51: };
add SERVICE_WORKER_FETCH_EVENT_RESULT_LAST =
SERVICE_WORKER_FETCH_RESULT_RESPONSE

[Charlie Reis, 2014-03-05 21:00:33]

content/ LGTM with style nits, plus one question about DEPS.

https://codereview.chromium.org/178343011/diff/60001/content/browser/service_...
File content/browser/service_worker/service_worker_browsertest.cc (right):

https://codereview.chromium.org/178343011/diff/60001/content/browser/service_...
content/browser/service_worker/service_worker_browsertest.cc:50: struct
FetchResult {
Style: structs should go above functions.

https://codereview.chromium.org/178343011/diff/60001/content/browser/service_...
content/browser/service_worker/service_worker_browsertest.cc:58: FetchResult*
out_result,
Style: output parameters should come after input parameters:
http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml?showone=Functi...

https://codereview.chromium.org/178343011/diff/60001/content/common/DEPS
File content/common/DEPS (right):

https://codereview.chromium.org/178343011/diff/60001/content/common/DEPS#newc...
content/common/DEPS:26:
"+third_party/WebKit/public/platform/WebServiceWorkerResponse.h",
I see that there's already a DEPS exception for WebServiceWorkerError above, so
this is probably fine.  Can you explain why this is needed, though?

[Tom Sepez, 2014-03-05 21:07:01]

https://codereview.chromium.org/178343011/diff/60001/content/common/service_w...
File content/common/service_worker/service_worker_types.h (right):

https://codereview.chromium.org/178343011/diff/60001/content/common/service_w...
content/common/service_worker/service_worker_types.h:48:
SERVICE_WORKER_FETCH_RESULT_FALLBACK,
nit:  The string "Event" appears in the type name, but not in these constants. 
Maybe that should be consistent.

[falken, 2014-03-06 15:58:53]

Thanks for the comments! Replies inline.

+tkent: Can you approve or weigh in on the DEPS issue?

https://codereview.chromium.org/178343011/diff/60001/content/browser/service_...
File content/browser/service_worker/service_worker_browsertest.cc (right):

https://codereview.chromium.org/178343011/diff/60001/content/browser/service_...
content/browser/service_worker/service_worker_browsertest.cc:50: struct
FetchResult {
On 2014/03/05 21:00:34, Charlie Reis wrote:
> Style: structs should go above functions.

Done.

https://codereview.chromium.org/178343011/diff/60001/content/browser/service_...
content/browser/service_worker/service_worker_browsertest.cc:58: FetchResult*
out_result,
On 2014/03/05 21:00:34, Charlie Reis wrote:
> Style: output parameters should come after input parameters:
>
http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml?showone=Functi...

I think I need this ordering so Bind can be used in CreateResponseReceiver to
make a FetchCallback callback function, which is passed to DispatchFetchEvent.

https://codereview.chromium.org/178343011/diff/60001/content/common/DEPS
File content/common/DEPS (right):

https://codereview.chromium.org/178343011/diff/60001/content/common/DEPS#newc...
content/common/DEPS:26:
"+third_party/WebKit/public/platform/WebServiceWorkerResponse.h",
On 2014/03/05 21:00:34, Charlie Reis wrote:
> I see that there's already a DEPS exception for WebServiceWorkerError above,
so
> this is probably fine.  Can you explain why this is needed, though?

Hmm.. it's not strictly needed but ServiceWorkerResponse is essentially just an
IPC-able version of WebServiceWorkerResponse so it seemed most convenient to
allow passing in WebServiceWorkerResponse to ServiceWorkerResponse's
constructor. The alternative would be to have a function somewhere else that
does the conversion, which I wouldn't mind doing.

WebServiceWorkerResponse is pretty simple, basically a bag of properties, but
not POD so it can't form an IPC message itself. If WebServiceWorkerResponse
changes, so should ServiceWorkerResponse, so the dependency exists regardless of
DEPS. WDYT?

Also, the DEPS change would require approval from a public/platform owner, so
+tkent.

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

https://codereview.chromium.org/178343011/diff/60001/content/common/service_w...
content/common/service_worker/service_worker_messages.h:29:
IPC_ENUM_TRAITS(content::ServiceWorkerFetchEventResult)
On 2014/03/05 19:45:02, Tom Sepez wrote:
> use IPC_ENUM_TRAITS_MAX_VALUE(content::ServiceWorkerFetchEventResult,
> SERVICE_WORKER_FETCH_EVENT_RESULT_LAST)

Done.

https://codereview.chromium.org/178343011/diff/60001/content/common/service_w...
File content/common/service_worker/service_worker_types.h (right):

https://codereview.chromium.org/178343011/diff/60001/content/common/service_w...
content/common/service_worker/service_worker_types.h:48:
SERVICE_WORKER_FETCH_RESULT_FALLBACK,
On 2014/03/05 21:07:01, Tom Sepez wrote:
> nit:  The string "Event" appears in the type name, but not in these constants.

> Maybe that should be consistent.

Agreed, especially since we want to distinguish between fetch() and FetchEvent
for ServiceWorker. Done.

https://codereview.chromium.org/178343011/diff/60001/content/common/service_w...
content/common/service_worker/service_worker_types.h:51: };
On 2014/03/05 19:45:02, Tom Sepez wrote:
> add SERVICE_WORKER_FETCH_EVENT_RESULT_LAST =
> SERVICE_WORKER_FETCH_RESULT_RESPONSE

Done.

[Charlie Reis, 2014-03-06 18:59:04]

@jam: Can I get you to weigh in on the DEPS change?

Otherwise still LGTM.

https://codereview.chromium.org/178343011/diff/60001/content/browser/service_...
File content/browser/service_worker/service_worker_browsertest.cc (right):

https://codereview.chromium.org/178343011/diff/60001/content/browser/service_...
content/browser/service_worker/service_worker_browsertest.cc:58: FetchResult*
out_result,
On 2014/03/06 15:58:54, falken wrote:
> On 2014/03/05 21:00:34, Charlie Reis wrote:
> > Style: output parameters should come after input parameters:
> >
>
http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml?showone=Functi...
> 
> I think I need this ordering so Bind can be used in CreateResponseReceiver to
> make a FetchCallback callback function, which is passed to DispatchFetchEvent.

Ah, ok.  Maybe call that out in a comment?

https://codereview.chromium.org/178343011/diff/60001/content/common/DEPS
File content/common/DEPS (right):

https://codereview.chromium.org/178343011/diff/60001/content/common/DEPS#newc...
content/common/DEPS:26:
"+third_party/WebKit/public/platform/WebServiceWorkerResponse.h",
On 2014/03/06 15:58:54, falken wrote:
> On 2014/03/05 21:00:34, Charlie Reis wrote:
> > I see that there's already a DEPS exception for WebServiceWorkerError above,
> so
> > this is probably fine.  Can you explain why this is needed, though?
> 
> Hmm.. it's not strictly needed but ServiceWorkerResponse is essentially just
an
> IPC-able version of WebServiceWorkerResponse so it seemed most convenient to
> allow passing in WebServiceWorkerResponse to ServiceWorkerResponse's
> constructor. The alternative would be to have a function somewhere else that
> does the conversion, which I wouldn't mind doing.
> 
> WebServiceWorkerResponse is pretty simple, basically a bag of properties, but
> not POD so it can't form an IPC message itself. If WebServiceWorkerResponse
> changes, so should ServiceWorkerResponse, so the dependency exists regardless
of
> DEPS. WDYT?
> 
> Also, the DEPS change would require approval from a public/platform owner, so
> +tkent.

+jam for his opinion.

[jam, 2014-03-06 21:22:43]

https://codereview.chromium.org/178343011/diff/60001/content/common/DEPS
File content/common/DEPS (right):

https://codereview.chromium.org/178343011/diff/60001/content/common/DEPS#newc...
content/common/DEPS:26:
"+third_party/WebKit/public/platform/WebServiceWorkerResponse.h",
On 2014/03/06 18:59:05, Charlie Reis wrote:
> On 2014/03/06 15:58:54, falken wrote:
> > On 2014/03/05 21:00:34, Charlie Reis wrote:
> > > I see that there's already a DEPS exception for WebServiceWorkerError
above,
> > so
> > > this is probably fine.  Can you explain why this is needed, though?
> > 
> > Hmm.. it's not strictly needed but ServiceWorkerResponse is essentially just
> an
> > IPC-able version of WebServiceWorkerResponse so it seemed most convenient to
> > allow passing in WebServiceWorkerResponse to ServiceWorkerResponse's
> > constructor. The alternative would be to have a function somewhere else that
> > does the conversion, which I wouldn't mind doing.
> > 
> > WebServiceWorkerResponse is pretty simple, basically a bag of properties,
but
> > not POD so it can't form an IPC message itself. If WebServiceWorkerResponse
> > changes, so should ServiceWorkerResponse, so the dependency exists
regardless
> of
> > DEPS. WDYT?
> > 
> > Also, the DEPS change would require approval from a public/platform owner,
so
> > +tkent.
> 
> +jam for his opinion.

this doesn't pass the guideline in the common above, as it's not a strictly
enum/pod header. this wouldn't link in the chrome release build, since the
browser dll (which links in common) wouldn't link in blink

[kinuko, 2014-03-07 00:40:00]

On 2014/03/06 15:58:53, falken wrote:
> Thanks for the comments! Replies inline.
> 
> +tkent: Can you approve or weigh in on the DEPS issue?
> 
>
https://codereview.chromium.org/178343011/diff/60001/content/browser/service_...
> File content/browser/service_worker/service_worker_browsertest.cc (right):
> 
>
https://codereview.chromium.org/178343011/diff/60001/content/browser/service_...
> content/browser/service_worker/service_worker_browsertest.cc:50: struct
> FetchResult {
> On 2014/03/05 21:00:34, Charlie Reis wrote:
> > Style: structs should go above functions.
> 
> Done.
> 
>
https://codereview.chromium.org/178343011/diff/60001/content/browser/service_...
> content/browser/service_worker/service_worker_browsertest.cc:58: FetchResult*
> out_result,
> On 2014/03/05 21:00:34, Charlie Reis wrote:
> > Style: output parameters should come after input parameters:
> >
>
http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml?showone=Functi...
> 
> I think I need this ordering so Bind can be used in CreateResponseReceiver to
> make a FetchCallback callback function, which is passed to DispatchFetchEvent.
> 
> https://codereview.chromium.org/178343011/diff/60001/content/common/DEPS
> File content/common/DEPS (right):
> 
>
https://codereview.chromium.org/178343011/diff/60001/content/common/DEPS#newc...
> content/common/DEPS:26:
> "+third_party/WebKit/public/platform/WebServiceWorkerResponse.h",
> On 2014/03/05 21:00:34, Charlie Reis wrote:
> > I see that there's already a DEPS exception for WebServiceWorkerError above,
> so
> > this is probably fine.  Can you explain why this is needed, though?
> 
> Hmm.. it's not strictly needed but ServiceWorkerResponse is essentially just
an
> IPC-able version of WebServiceWorkerResponse so it seemed most convenient to
> allow passing in WebServiceWorkerResponse to ServiceWorkerResponse's
> constructor. The alternative would be to have a function somewhere else that
> does the conversion, which I wouldn't mind doing.

I haven't taken a closer look at DEPS, but I think we usually do this.

[falken, 2014-03-07 01:56:50]

Thanks for the comments. I removed the DEPS change. Is the new patch okay?

https://codereview.chromium.org/178343011/diff/60001/content/browser/service_...
File content/browser/service_worker/service_worker_browsertest.cc (right):

https://codereview.chromium.org/178343011/diff/60001/content/browser/service_...
content/browser/service_worker/service_worker_browsertest.cc:58: FetchResult*
out_result,
On 2014/03/06 18:59:05, Charlie Reis wrote:
> On 2014/03/06 15:58:54, falken wrote:
> > On 2014/03/05 21:00:34, Charlie Reis wrote:
> > > Style: output parameters should come after input parameters:
> > >
> >
>
http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml?showone=Functi...
> > 
> > I think I need this ordering so Bind can be used in CreateResponseReceiver
to
> > make a FetchCallback callback function, which is passed to
DispatchFetchEvent.
> 
> Ah, ok.  Maybe call that out in a comment?

Done.

https://codereview.chromium.org/178343011/diff/60001/content/common/DEPS
File content/common/DEPS (right):

https://codereview.chromium.org/178343011/diff/60001/content/common/DEPS#newc...
content/common/DEPS:26:
"+third_party/WebKit/public/platform/WebServiceWorkerResponse.h",
On 2014/03/06 21:22:43, jam wrote:
> On 2014/03/06 18:59:05, Charlie Reis wrote:
> > On 2014/03/06 15:58:54, falken wrote:
> > > On 2014/03/05 21:00:34, Charlie Reis wrote:
> > > > I see that there's already a DEPS exception for WebServiceWorkerError
> above,
> > > so
> > > > this is probably fine.  Can you explain why this is needed, though?
> > > 
> > > Hmm.. it's not strictly needed but ServiceWorkerResponse is essentially
just
> > an
> > > IPC-able version of WebServiceWorkerResponse so it seemed most convenient
to
> > > allow passing in WebServiceWorkerResponse to ServiceWorkerResponse's
> > > constructor. The alternative would be to have a function somewhere else
that
> > > does the conversion, which I wouldn't mind doing.
> > > 
> > > WebServiceWorkerResponse is pretty simple, basically a bag of properties,
> but
> > > not POD so it can't form an IPC message itself. If
WebServiceWorkerResponse
> > > changes, so should ServiceWorkerResponse, so the dependency exists
> regardless
> > of
> > > DEPS. WDYT?
> > > 
> > > Also, the DEPS change would require approval from a public/platform owner,
> so
> > > +tkent.
> > 
> > +jam for his opinion.
> 
> this doesn't pass the guideline in the common above, as it's not a strictly
> enum/pod header. this wouldn't link in the chrome release build, since the
> browser dll (which links in common) wouldn't link in blink

OK, I removed the DEPS change.

Since just one place is doing the conversion now, I manually convert there. We
can move it to a separate function later if needed.

[michaeln, 2014-03-07 02:47:59]

drive-by-comments

https://codereview.chromium.org/178343011/diff/100001/content/browser/service...
File content/browser/service_worker/service_worker_version.cc (right):

https://codereview.chromium.org/178343011/diff/100001/content/browser/service...
content/browser/service_worker/service_worker_version.cc:80:
ServiceWorkerFetchEventResult result;
initialize this value to something since its passed on line 85, or change line
85 to pass a constant value

https://codereview.chromium.org/178343011/diff/100001/content/common/service_...
File content/common/service_worker/service_worker_types.h (right):

https://codereview.chromium.org/178343011/diff/100001/content/common/service_...
content/common/service_worker/service_worker_types.h:57: const std::string&
method,
how is method relevant for a response object?

[falken, 2014-03-07 04:40:23]

https://codereview.chromium.org/178343011/diff/100001/content/browser/service...
File content/browser/service_worker/service_worker_version.cc (right):

https://codereview.chromium.org/178343011/diff/100001/content/browser/service...
content/browser/service_worker/service_worker_version.cc:80:
ServiceWorkerFetchEventResult result;
On 2014/03/07 02:48:00, michaeln wrote:
> initialize this value to something since its passed on line 85, or change line
> 85 to pass a constant value

Done. I also realized we should initialize status_code in
ServiceWorkerResponse's default constructor.

https://codereview.chromium.org/178343011/diff/100001/content/common/service_...
File content/common/service_worker/service_worker_types.h (right):

https://codereview.chromium.org/178343011/diff/100001/content/common/service_...
content/common/service_worker/service_worker_types.h:57: const std::string&
method,
On 2014/03/07 02:48:00, michaeln wrote:
> how is method relevant for a response object?

Perhaps it's not needed. It's part of the spec so the Response IDL and
WebServiceWorkerResponse have it (it should also have the same URL as the
Request but I just didn't add it to WebServiceWorkerResponse yet).

[falken, 2014-03-07 08:21:47]

Since the outstanding comments have been addressed I'm setting the cq bit. Let
me know if you have comments on the latest patch and I'll revise it.

[falken, 2014-03-07 08:22:07]

The CQ bit was checked by falken@chromium.org

[commit-bot: I haz the power, 2014-03-07 08:25:08]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/falken@chromium.org/178343011/120002

[commit-bot: I haz the power, 2014-03-07 15:18:19]

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

[commit-bot: I haz the power, 2014-03-07 15:18:20]

Retried try job too often on win_rel for step(s) content_browsertests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=win_rel&nu...

[Charlie Reis, 2014-03-07 18:25:29]

On 2014/03/07 08:21:47, falken wrote:
> Since the outstanding comments have been addressed I'm setting the cq bit. Let
> me know if you have comments on the latest patch and I'll revise it.

LGTM.  Thanks for removing the DEPS change.

[falken, 2014-03-10 23:42:45]

The CQ bit was checked by falken@chromium.org

[commit-bot: I haz the power, 2014-03-11 00:17:26]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/falken@chromium.org/178343011/120002

[commit-bot: I haz the power, 2014-03-11 05:12:16]

Change committed as 256132