Add ServiceWorker InstallPhaseEvent.waitUntil() layout test.

Add ServiceWorker InstallPhaseEvent.waitUntil() layout test.
    
Add InstallPhaseEvent layout tests for both "install" and "activate" events.

Fix the rejection precedence when multiple promises waiting on an event.

Rename the "active" state to "activated" and "deactivated" state to "redundant", see:
https://slightlyoff.github.io/ServiceWorker/spec/service_worker/#service-worker-state.

BUG=375132
TEST=http/tests/serviceworker/install-phase-event-waituntil.html

Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=177461

[xiang, 2014-06-27 12:13:56]

The rejection test depends on CL: https://codereview.chromium.org/355163002/.
PTAL, thanks.

[xiang, 2014-06-30 03:15:46]

There maybe a spec mismatch for waitUntil() impl, when multiple waitUntil()
calls are made.

In
spec(http://slightlyoff.github.io/ServiceWorker/spec/service_worker/#wait-until-method),
the event flags(extend lifetime flag & wait-until reject flag) are updated
directly for every waitUntil() call.

However in the Blink impl(with this change), the "extend lifetime flag" will
only set after all waitUntil() promises are fufilled, and the "wait-until reject
flag" will unset if any promise is rejected.

[falken, 2014-06-30 04:35:31]

Some questions/comments.

I'm also not sure I totally understand your comment #2 about multiple waitUntil.
Could you please describe what the current implementation does, what it does
after this change, and what the spec says? Thanks!

https://codereview.chromium.org/352423005/diff/20001/LayoutTests/http/tests/s...
File LayoutTests/http/tests/serviceworker/install-phase-event-waituntil.html
(right):

https://codereview.chromium.org/352423005/diff/20001/LayoutTests/http/tests/s...
LayoutTests/http/tests/serviceworker/install-phase-event-waituntil.html:8: var
worker_script = 'resources/install-phase-event-waituntil.js';
Unfortunately Service Worker layout tests don't have a consistent style, but
they try to either be W3C-style (snake_case for functions and variables) or
modern Blink-style (camelCase for functions and variables). Either one is fine,
just pick one and be consistent throughout the test.

https://codereview.chromium.org/352423005/diff/20001/LayoutTests/http/tests/s...
LayoutTests/http/tests/serviceworker/install-phase-event-waituntil.html:26:
worker.postMessage({port: channel.port2}, [channel.port2]);
I might be missing something. The async tests run in parallel. What guarantees
that the worker that responds to this port message is our intended target? E.g.,
how do you know the "installed-fulfilled" worker gets the message sent within
"install-fulfilled" and not the "activate-fulfilled" worker?

https://codereview.chromium.org/352423005/diff/20001/LayoutTests/http/tests/s...
LayoutTests/http/tests/serviceworker/install-phase-event-waituntil.html:39:
assert_true(obj.synced, '"installed" state should changed after sync.');
This description is a bit unclear: "state should changed" is unclear and "sync"
is a bit implementation-specific to this test. Maybe: "the state should be
'installed' after the waitUntil promise for 'installing' is resolved"

https://codereview.chromium.org/352423005/diff/20001/LayoutTests/http/tests/s...
File
LayoutTests/http/tests/serviceworker/resources/install-phase-event-waituntil.js
(right):

https://codereview.chromium.org/352423005/diff/20001/LayoutTests/http/tests/s...
LayoutTests/http/tests/serviceworker/resources/install-phase-event-waituntil.js:47:
var test_switch = stripScopeName(scope);
could you use "self.scope" to make clear it's a global?

https://codereview.chromium.org/352423005/diff/20001/LayoutTests/http/tests/s...
LayoutTests/http/tests/serviceworker/resources/install-phase-event-waituntil.js:58:
} else if (test_switch == 'activate-rejected') {
these look like they'd be more readable as a switch statement

[falken, 2014-06-30 04:42:16]

On 2014/06/30 04:35:31, falken wrote:
> Some questions/comments.
> 
> I'm also not sure I totally understand your comment #2 about multiple
waitUntil.
> Could you please describe what the current implementation does, what it does
> after this change, and what the spec says? Thanks!
> 
>
https://codereview.chromium.org/352423005/diff/20001/LayoutTests/http/tests/s...
> File LayoutTests/http/tests/serviceworker/install-phase-event-waituntil.html
> (right):
> 
>
https://codereview.chromium.org/352423005/diff/20001/LayoutTests/http/tests/s...
> LayoutTests/http/tests/serviceworker/install-phase-event-waituntil.html:8: var
> worker_script = 'resources/install-phase-event-waituntil.js';
> Unfortunately Service Worker layout tests don't have a consistent style, but
> they try to either be W3C-style (snake_case for functions and variables) or
> modern Blink-style (camelCase for functions and variables). Either one is
fine,
> just pick one and be consistent throughout the test.
> 
>
https://codereview.chromium.org/352423005/diff/20001/LayoutTests/http/tests/s...
> LayoutTests/http/tests/serviceworker/install-phase-event-waituntil.html:26:
> worker.postMessage({port: channel.port2}, [channel.port2]);
> I might be missing something. The async tests run in parallel. What guarantees
> that the worker that responds to this port message is our intended target?
E.g.,
> how do you know the "installed-fulfilled" worker gets the message sent within
> "install-fulfilled" and not the "activate-fulfilled" worker?
> 
>
https://codereview.chromium.org/352423005/diff/20001/LayoutTests/http/tests/s...
> LayoutTests/http/tests/serviceworker/install-phase-event-waituntil.html:39:
> assert_true(obj.synced, '"installed" state should changed after sync.');
> This description is a bit unclear: "state should changed" is unclear and
"sync"
> is a bit implementation-specific to this test. Maybe: "the state should be
> 'installed' after the waitUntil promise for 'installing' is resolved"
> 
>
https://codereview.chromium.org/352423005/diff/20001/LayoutTests/http/tests/s...
> File
>
LayoutTests/http/tests/serviceworker/resources/install-phase-event-waituntil.js
> (right):
> 
>
https://codereview.chromium.org/352423005/diff/20001/LayoutTests/http/tests/s...
>
LayoutTests/http/tests/serviceworker/resources/install-phase-event-waituntil.js:47:
> var test_switch = stripScopeName(scope);
> could you use "self.scope" to make clear it's a global?
> 
>
https://codereview.chromium.org/352423005/diff/20001/LayoutTests/http/tests/s...
>
LayoutTests/http/tests/serviceworker/resources/install-phase-event-waituntil.js:58:
> } else if (test_switch == 'activate-rejected') {
> these look like they'd be more readable as a switch statement

You can also use BUG=375132 in the CL description, since this does some of that
work.

[xiang, 2014-06-30 06:37:11]

https://codereview.chromium.org/352423005/diff/20001/LayoutTests/http/tests/s...
File LayoutTests/http/tests/serviceworker/install-phase-event-waituntil.html
(right):

https://codereview.chromium.org/352423005/diff/20001/LayoutTests/http/tests/s...
LayoutTests/http/tests/serviceworker/install-phase-event-waituntil.html:8: var
worker_script = 'resources/install-phase-event-waituntil.js';
On 2014/06/30 04:35:31, falken wrote:
> Unfortunately Service Worker layout tests don't have a consistent style, but
> they try to either be W3C-style (snake_case for functions and variables) or
> modern Blink-style (camelCase for functions and variables). Either one is
fine,
> just pick one and be consistent throughout the test.

I will follow the Blink-style, thanks for the info.

https://codereview.chromium.org/352423005/diff/20001/LayoutTests/http/tests/s...
LayoutTests/http/tests/serviceworker/install-phase-event-waituntil.html:26:
worker.postMessage({port: channel.port2}, [channel.port2]);
On 2014/06/30 04:35:31, falken wrote:
> I might be missing something. The async tests run in parallel. What guarantees
> that the worker that responds to this port message is our intended target?
E.g.,
> how do you know the "installed-fulfilled" worker gets the message sent within
> "install-fulfilled" and not the "activate-fulfilled" worker? 

Yes, they're parallel. I think the passing "worker" parameter will guarantee
different worker gets different MessagePort.
And different MessagePort will talked with different worker directly.

https://codereview.chromium.org/352423005/diff/20001/LayoutTests/http/tests/s...
LayoutTests/http/tests/serviceworker/install-phase-event-waituntil.html:39:
assert_true(obj.synced, '"installed" state should changed after sync.');
On 2014/06/30 04:35:31, falken wrote:
> This description is a bit unclear: "state should changed" is unclear and
"sync"
> is a bit implementation-specific to this test. Maybe: "the state should be
> 'installed' after the waitUntil promise for 'installing' is resolved"

will change that.

https://codereview.chromium.org/352423005/diff/20001/LayoutTests/http/tests/s...
File
LayoutTests/http/tests/serviceworker/resources/install-phase-event-waituntil.js
(right):

https://codereview.chromium.org/352423005/diff/20001/LayoutTests/http/tests/s...
LayoutTests/http/tests/serviceworker/resources/install-phase-event-waituntil.js:47:
var test_switch = stripScopeName(scope);
On 2014/06/30 04:35:31, falken wrote:
> could you use "self.scope" to make clear it's a global?

OK, I will change that

https://codereview.chromium.org/352423005/diff/20001/LayoutTests/http/tests/s...
LayoutTests/http/tests/serviceworker/resources/install-phase-event-waituntil.js:58:
} else if (test_switch == 'activate-rejected') {
On 2014/06/30 04:35:31, falken wrote:
> these look like they'd be more readable as a switch statement

Yes, will change, thanks.

[xiang, 2014-06-30 06:59:40]

On 2014/06/30 04:35:31, falken wrote:
> Some questions/comments.
> 
> I'm also not sure I totally understand your comment #2 about multiple
waitUntil.
> Could you please describe what the current implementation does, what it does
> after this change, and what the spec says? Thanks!
> 

Quoted from spec, waitUntil(f):
"Run the following steps asynchronously:
   1. Set the extend lifetime flag.
   2. Wait until f settles.
   3. If f rejects with an exception, then:
       1. Reject promise with that exception.
       2. Set the wait-until reject flag.
   4. Else if f resolves with a value, then:
       1. Resolve promise with that value.
   5. Unset the extend lifetime flag."

[Install]] :
"3. If event's extend lifetime flag is set, then:
     1. Wait until event's extend lifetime flag is unset.
     2. If event's wait-until reject flag is set, then:
         1. Set installFalied to true."

The mismatch happens when multiple waitUntil happens:
oninstall(e) {
   e.waitUntil(promise1);
   e.waitUntil(promise2);
}

The flags change in spec is like below pseudo code:
extend_flag = !(promise1-resolved-or-rejected || promise2-resovled-or-rejected)
reject_flag = promise1-rejected || promise1-rejected

The flags change before this CL:
extend_flag = !(promise1-resolved-or-rejected && promise2-resolved-or-rejected)
reject_flag = promise1-rejected || promise1-rejected

after this CL:
extend_flag = !((promise1-resolved && promise2-resovled) || promise1-rejected ||
promise1-rejected)
reject_flag = promise1-rejected || promise1-rejected

[jsbell, 2014-07-01 16:16:49]

lgtm overall, with questions, suggestions, and nits.

https://codereview.chromium.org/352423005/diff/40001/LayoutTests/http/tests/s...
File LayoutTests/http/tests/serviceworker/install-phase-event-waituntil.html
(right):

https://codereview.chromium.org/352423005/diff/40001/LayoutTests/http/tests/s...
LayoutTests/http/tests/serviceworker/install-phase-event-waituntil.html:30: var
t = async_test('Test install event waitUntil fulfilled.');
I think dominicc was trying to get us to standardize on this style:

async_test(function(t) {
 ...
}, 'description');

... to avoid the IIFE wrapper, but we're not consistent yet so it's okay to keep
this and we can update it later.

https://codereview.chromium.org/352423005/diff/40001/LayoutTests/http/tests/s...
File
LayoutTests/http/tests/serviceworker/resources/install-phase-event-waituntil.js
(right):

https://codereview.chromium.org/352423005/diff/40001/LayoutTests/http/tests/s...
LayoutTests/http/tests/serviceworker/resources/install-phase-event-waituntil.js:17:
// Make sure oninstall/onactivate callback finishes first.
Is it really necessary for this to run in a subsequent tick of the even loop, or
is just running in a subsequent microtask sufficient?

If it's just after the callback finishes, then a microtask would be sufficient,
e.g.:

return Promise.resolve().then(function() {
  var port = ...
}).then(function(port) { 
  ... 
});

If it does need to be in a subsequent turn of the event loop, can you document
that?

https://codereview.chromium.org/352423005/diff/40001/LayoutTests/http/tests/s...
LayoutTests/http/tests/serviceworker/resources/install-phase-event-waituntil.js:38:
setTimeout(reject, 0);
Add comment similar to the above, i.e. why `return Promise.reject()` is not
sufficient.

https://codereview.chromium.org/352423005/diff/40001/LayoutTests/http/tests/s...
LayoutTests/http/tests/serviceworker/resources/install-phase-event-waituntil.js:71:
e.waitUntil(new Promise(function(resolve, reject) {
Why not rejectPromise() here?

https://codereview.chromium.org/352423005/diff/40001/Source/modules/servicewo...
File Source/modules/serviceworkers/ServiceWorker.cpp (right):

https://codereview.chromium.org/352423005/diff/40001/Source/modules/servicewo...
Source/modules/serviceworkers/ServiceWorker.cpp:116:
DEFINE_STATIC_LOCAL(AtomicString, active, ("activated",
AtomicString::ConstructFromLiteral));
Rename the variable as well, for consistency?

https://codereview.chromium.org/352423005/diff/40001/Source/modules/servicewo...
File Source/modules/serviceworkers/WaitUntilObserver.cpp (right):

https://codereview.chromium.org/352423005/diff/40001/Source/modules/servicewo...
Source/modules/serviceworkers/WaitUntilObserver.cpp:111: if (!executionContext()
|| (!m_hasError && --m_pendingActivity))
Is the assertion in the destructor still valid if some decrement requests are
ignored?

https://codereview.chromium.org/352423005/diff/40001/public/platform/WebServi...
File public/platform/WebServiceWorkerState.h (right):

https://codereview.chromium.org/352423005/diff/40001/public/platform/WebServi...
public/platform/WebServiceWorkerState.h:16: WebServiceWorkerStateActive,
Change this name too? Or at least a FIXME to do so later, so that the enum
matches the spec?

[xiang, 2014-07-02 05:10:43]

Thanks a lot for the review.

https://codereview.chromium.org/352423005/diff/40001/LayoutTests/http/tests/s...
File LayoutTests/http/tests/serviceworker/install-phase-event-waituntil.html
(right):

https://codereview.chromium.org/352423005/diff/40001/LayoutTests/http/tests/s...
LayoutTests/http/tests/serviceworker/install-phase-event-waituntil.html:30: var
t = async_test('Test install event waitUntil fulfilled.');
On 2014/07/01 16:16:48, jsbell wrote:
> I think dominicc was trying to get us to standardize on this style:
> 
> async_test(function(t) {
>  ...
> }, 'description');
> 
> ... to avoid the IIFE wrapper, but we're not consistent yet so it's okay to
keep
> this and we can update it later.

will adapt this style.

https://codereview.chromium.org/352423005/diff/40001/LayoutTests/http/tests/s...
File
LayoutTests/http/tests/serviceworker/resources/install-phase-event-waituntil.js
(right):

https://codereview.chromium.org/352423005/diff/40001/LayoutTests/http/tests/s...
LayoutTests/http/tests/serviceworker/resources/install-phase-event-waituntil.js:17:
// Make sure oninstall/onactivate callback finishes first.
On 2014/07/01 16:16:48, jsbell wrote:
> Is it really necessary for this to run in a subsequent tick of the even loop,
or
> is just running in a subsequent microtask sufficient?
> 
> If it's just after the callback finishes, then a microtask would be
sufficient,
> e.g.:
> 
> return Promise.resolve().then(function() {
>   var port = ...
> }).then(function(port) { 
>   ... 
> });
> 
> If it does need to be in a subsequent turn of the event loop, can you document
> that?

Yes, microtask is sufficient here, thanks!

https://codereview.chromium.org/352423005/diff/40001/LayoutTests/http/tests/s...
LayoutTests/http/tests/serviceworker/resources/install-phase-event-waituntil.js:38:
setTimeout(reject, 0);
On 2014/07/01 16:16:48, jsbell wrote:
> Add comment similar to the above, i.e. why `return Promise.reject()` is not
> sufficient.
will add.

https://codereview.chromium.org/352423005/diff/40001/LayoutTests/http/tests/s...
LayoutTests/http/tests/serviceworker/resources/install-phase-event-waituntil.js:71:
e.waitUntil(new Promise(function(resolve, reject) {
On 2014/07/01 16:16:48, jsbell wrote:
> Why not rejectPromise() here?
Sure, I will change it.

https://codereview.chromium.org/352423005/diff/40001/Source/modules/servicewo...
File Source/modules/serviceworkers/ServiceWorker.cpp (right):

https://codereview.chromium.org/352423005/diff/40001/Source/modules/servicewo...
Source/modules/serviceworkers/ServiceWorker.cpp:116:
DEFINE_STATIC_LOCAL(AtomicString, active, ("activated",
AtomicString::ConstructFromLiteral));
On 2014/07/01 16:16:48, jsbell wrote:
> Rename the variable as well, for consistency?

OK.

https://codereview.chromium.org/352423005/diff/40001/Source/modules/servicewo...
File Source/modules/serviceworkers/WaitUntilObserver.cpp (right):

https://codereview.chromium.org/352423005/diff/40001/Source/modules/servicewo...
Source/modules/serviceworkers/WaitUntilObserver.cpp:111: if (!executionContext()
|| (!m_hasError && --m_pendingActivity))
On 2014/07/01 16:16:48, jsbell wrote:
> Is the assertion in the destructor still valid if some decrement requests are
> ignored?

I will remove assertion in desctructor as it's not valid anymore.

https://codereview.chromium.org/352423005/diff/40001/public/platform/WebServi...
File public/platform/WebServiceWorkerState.h (right):

https://codereview.chromium.org/352423005/diff/40001/public/platform/WebServi...
public/platform/WebServiceWorkerState.h:16: WebServiceWorkerStateActive,
On 2014/07/01 16:16:48, jsbell wrote:
> Change this name too? Or at least a FIXME to do so later, so that the enum
> matches the spec?

will change it.

https://codereview.chromium.org/352423005/diff/40001/public/platform/WebServi...
public/platform/WebServiceWorkerState.h:16: WebServiceWorkerStateActive,
On 2014/07/01 16:16:48, jsbell wrote:
> Change this name too? Or at least a FIXME to do so later, so that the enum
> matches the spec?

will change.

[xiang, 2014-07-02 08:17:59]

On 2014/07/02 05:10:43, xiang wrote:
> Thanks a lot for the review.
> 
>
https://codereview.chromium.org/352423005/diff/40001/LayoutTests/http/tests/s...
> File LayoutTests/http/tests/serviceworker/install-phase-event-waituntil.html
> (right):
> 
>
https://codereview.chromium.org/352423005/diff/40001/LayoutTests/http/tests/s...
> LayoutTests/http/tests/serviceworker/install-phase-event-waituntil.html:30:
var
> t = async_test('Test install event waitUntil fulfilled.');
> On 2014/07/01 16:16:48, jsbell wrote:
> > I think dominicc was trying to get us to standardize on this style:
> > 
> > async_test(function(t) {
> >  ...
> > }, 'description');
> > 
> > ... to avoid the IIFE wrapper, but we're not consistent yet so it's okay to
> keep
> > this and we can update it later.
> 
> will adapt this style.
> 
>
https://codereview.chromium.org/352423005/diff/40001/LayoutTests/http/tests/s...
> File
>
LayoutTests/http/tests/serviceworker/resources/install-phase-event-waituntil.js
> (right):
> 
>
https://codereview.chromium.org/352423005/diff/40001/LayoutTests/http/tests/s...
>
LayoutTests/http/tests/serviceworker/resources/install-phase-event-waituntil.js:17:
> // Make sure oninstall/onactivate callback finishes first.
> On 2014/07/01 16:16:48, jsbell wrote:
> > Is it really necessary for this to run in a subsequent tick of the even
loop,
> or
> > is just running in a subsequent microtask sufficient?
> > 
> > If it's just after the callback finishes, then a microtask would be
> sufficient,
> > e.g.:
> > 
> > return Promise.resolve().then(function() {
> >   var port = ...
> > }).then(function(port) { 
> >   ... 
> > });
> > 
> > If it does need to be in a subsequent turn of the event loop, can you
document
> > that?
> 
> Yes, microtask is sufficient here, thanks!
> 
>
https://codereview.chromium.org/352423005/diff/40001/LayoutTests/http/tests/s...
>
LayoutTests/http/tests/serviceworker/resources/install-phase-event-waituntil.js:38:
> setTimeout(reject, 0);
> On 2014/07/01 16:16:48, jsbell wrote:
> > Add comment similar to the above, i.e. why `return Promise.reject()` is not
> > sufficient.
> will add.
> 
>
https://codereview.chromium.org/352423005/diff/40001/LayoutTests/http/tests/s...
>
LayoutTests/http/tests/serviceworker/resources/install-phase-event-waituntil.js:71:
> e.waitUntil(new Promise(function(resolve, reject) {
> On 2014/07/01 16:16:48, jsbell wrote:
> > Why not rejectPromise() here?
> Sure, I will change it.
> 
>
https://codereview.chromium.org/352423005/diff/40001/Source/modules/servicewo...
> File Source/modules/serviceworkers/ServiceWorker.cpp (right):
> 
>
https://codereview.chromium.org/352423005/diff/40001/Source/modules/servicewo...
> Source/modules/serviceworkers/ServiceWorker.cpp:116:
> DEFINE_STATIC_LOCAL(AtomicString, active, ("activated",
> AtomicString::ConstructFromLiteral));
> On 2014/07/01 16:16:48, jsbell wrote:
> > Rename the variable as well, for consistency?
> 
> OK.
> 
>
https://codereview.chromium.org/352423005/diff/40001/Source/modules/servicewo...
> File Source/modules/serviceworkers/WaitUntilObserver.cpp (right):
> 
>
https://codereview.chromium.org/352423005/diff/40001/Source/modules/servicewo...
> Source/modules/serviceworkers/WaitUntilObserver.cpp:111: if
(!executionContext()
> || (!m_hasError && --m_pendingActivity))
> On 2014/07/01 16:16:48, jsbell wrote:
> > Is the assertion in the destructor still valid if some decrement requests
are
> > ignored?
> 
> I will remove assertion in desctructor as it's not valid anymore.
> 
>
https://codereview.chromium.org/352423005/diff/40001/public/platform/WebServi...
> File public/platform/WebServiceWorkerState.h (right):
> 
>
https://codereview.chromium.org/352423005/diff/40001/public/platform/WebServi...
> public/platform/WebServiceWorkerState.h:16: WebServiceWorkerStateActive,
> On 2014/07/01 16:16:48, jsbell wrote:
> > Change this name too? Or at least a FIXME to do so later, so that the enum
> > matches the spec?
> 
> will change it.
> 
>
https://codereview.chromium.org/352423005/diff/40001/public/platform/WebServi...
> public/platform/WebServiceWorkerState.h:16: WebServiceWorkerStateActive,
> On 2014/07/01 16:16:48, jsbell wrote:
> > Change this name too? Or at least a FIXME to do so later, so that the enum
> > matches the spec?
> 
> will change.

Done

[jsbell, 2014-07-02 17:55:49]

https://codereview.chromium.org/352423005/diff/60001/public/platform/WebServi...
File public/platform/WebServiceWorkerState.h (right):

https://codereview.chromium.org/352423005/diff/60001/public/platform/WebServi...
public/platform/WebServiceWorkerState.h:18: WebServiceWorkerStateActive =
WebServiceWorkerStateActivated,
Please add a FIXME to remove these once the Chromium side has landed.

Also, you'll need a public API OWNERS reviewer to approve.

[xiang, 2014-07-03 05:55:29]

On 2014/07/02 17:55:49, jsbell wrote:
>
https://codereview.chromium.org/352423005/diff/60001/public/platform/WebServi...
> File public/platform/WebServiceWorkerState.h (right):
> 
>
https://codereview.chromium.org/352423005/diff/60001/public/platform/WebServi...
> public/platform/WebServiceWorkerState.h:18: WebServiceWorkerStateActive =
> WebServiceWorkerStateActivated,
> Please add a FIXME to remove these once the Chromium side has landed.
>
Done.
 
> Also, you'll need a public API OWNERS reviewer to approve.

abarth@ would you take a look of this? Thanks.

[abarth-chromium, 2014-07-03 06:35:04]

public/ LGTM (didn't look at the rest)

[xiang, 2014-07-03 07:07:24]

The CQ bit was checked by xiang.long@intel.com

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

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/xiang.long@intel.com/352423005/80001

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

FYI, CQ is re-trying this CL (attempt #1).
The failing builders are:
  mac_blink_rel on tryserver.blink
(http://build.chromium.org/p/tryserver.blink/builders/mac_blink_rel/builds/14081)

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

Change committed as 177461