Hook up new API for easy unlock to update lock screen

Hook up new easyUnlockPrivate API function for updating lock screen

This will replace screenlockPrivate methods for updating screenlock
icon, auth type, and message.

The cl starts migration of the Easy Unlocking logic from Chrome app
to native code. The new easyUnlockPrivate function should be removed once
the migration is complete (probably in M39). It moves resources used
on screen lock from Easy Unlock app to Chrome, and simplifies
generating icon URL to be used in the screenlock web ui.

Adds support for setting icon tooltip and animating the icon directly in
screenlock web ui (instead of calling showCustomIcon for each animation
frame, which can produce somewhat laggy animation).

BUG=393792, 397366, 397360, 385719, 402106
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=289784

[tbarzic, 2014-08-11 23:36:52]

xiyuan: main review
asargent: owner for extensions
dzhioev: owner for ui/login
rogerta: owner for chrome/browser/signin

[asargent_no_longer_on_chrome, 2014-08-12 16:27:03]

extensions parts lgtm

[xiyuan, 2014-08-12 18:09:47]

https://codereview.chromium.org/446743003/diff/440001/chrome/browser/extensio...
File chrome/browser/extensions/api/easy_unlock_private/easy_unlock_private_api.h
(right):

https://codereview.chromium.org/446743003/diff/440001/chrome/browser/extensio...
chrome/browser/extensions/api/easy_unlock_private/easy_unlock_private_api.h:171:
};
nit:
DISALLOW_COPY_AND_ASSIGN(
    EasyUnlockPrivateUpdateScreenlockStateFunction);

https://codereview.chromium.org/446743003/diff/440001/chrome/browser/signin/e...
File chrome/browser/signin/easy_unlock_screenlock_state_handler.cc (right):

https://codereview.chromium.org/446743003/diff/440001/chrome/browser/signin/e...
chrome/browser/signin/easy_unlock_screenlock_state_handler.cc:35: return
"chrome://theme/IDR_EASY_UNLOCK_UNLOCKED";
Do you have a seperate CL for those image resources?

https://codereview.chromium.org/446743003/diff/440001/chrome/browser/signin/e...
File chrome/browser/signin/easy_unlock_service.cc (right):

https://codereview.chromium.org/446743003/diff/440001/chrome/browser/signin/e...
chrome/browser/signin/easy_unlock_service.cc:52:
ScreenlockBridge::GetAuthenticatedUserEmail(profile),
EasyUnlockService is created with profile. Authenticated user name might not be
there when this gets called. We probably should defer
|screenlock_state_handler_| construction or make it get the user email when
needed.

https://codereview.chromium.org/446743003/diff/440001/chrome/browser/signin/s...
File chrome/browser/signin/screenlock_bridge.h (right):

https://codereview.chromium.org/446743003/diff/440001/chrome/browser/signin/s...
chrome/browser/signin/screenlock_bridge.h:92: size_t opacity_;
nit: document |opacity_| has range 0-100u.

https://codereview.chromium.org/446743003/diff/440001/chrome/browser/signin/s...
chrome/browser/signin/screenlock_bridge.h:94: scoped_ptr<base::string16>
tooltip_;
nit: Why use scoped_ptr for |tooltip_| and |icon_resource_url_|? It seems we
don't need to differentiate NULL and empty string thus this is not necessary.

https://codereview.chromium.org/446743003/diff/440001/chrome/common/extension...
File chrome/common/extensions/api/easy_unlock_private.idl (right):

https://codereview.chromium.org/446743003/diff/440001/chrome/common/extension...
chrome/common/extensions/api/easy_unlock_private.idl:37: // A phone eligible to
unlock the devioce is detected, but it is not allowed
nit: devioce -> device

https://codereview.chromium.org/446743003/diff/440001/ui/login/account_picker...
File ui/login/account_picker/user_pod_template.html (right):

https://codereview.chromium.org/446743003/diff/440001/ui/login/account_picker...
ui/login/account_picker/user_pod_template.html:32: <div
class="custom-icon"></div>
nit: since we replaceChild, we only needs "custom-icon-container" here as an
anchor.

[tbarzic, 2014-08-12 19:14:36]

https://codereview.chromium.org/446743003/diff/440001/chrome/browser/extensio...
File chrome/browser/extensions/api/easy_unlock_private/easy_unlock_private_api.h
(right):

https://codereview.chromium.org/446743003/diff/440001/chrome/browser/extensio...
chrome/browser/extensions/api/easy_unlock_private/easy_unlock_private_api.h:171:
};
On 2014/08/12 18:09:47, xiyuan wrote:
> nit:
> DISALLOW_COPY_AND_ASSIGN(
>     EasyUnlockPrivateUpdateScreenlockStateFunction);

Done.

https://codereview.chromium.org/446743003/diff/440001/chrome/browser/signin/e...
File chrome/browser/signin/easy_unlock_screenlock_state_handler.cc (right):

https://codereview.chromium.org/446743003/diff/440001/chrome/browser/signin/e...
chrome/browser/signin/easy_unlock_screenlock_state_handler.cc:35: return
"chrome://theme/IDR_EASY_UNLOCK_UNLOCKED";
On 2014/08/12 18:09:47, xiyuan wrote:
> Do you have a seperate CL for those image resources?

yep, I'll upload the cl today...

https://codereview.chromium.org/446743003/diff/440001/chrome/browser/signin/e...
File chrome/browser/signin/easy_unlock_service.cc (right):

https://codereview.chromium.org/446743003/diff/440001/chrome/browser/signin/e...
chrome/browser/signin/easy_unlock_service.cc:52:
ScreenlockBridge::GetAuthenticatedUserEmail(profile),
On 2014/08/12 18:09:47, xiyuan wrote:
> EasyUnlockService is created with profile. Authenticated user name might not
be
> there when this gets called. We probably should defer
> |screenlock_state_handler_| construction or make it get the user email when
> needed.

Done. Now creating |screenlock_state_handler_| lazily.

https://codereview.chromium.org/446743003/diff/440001/chrome/browser/signin/s...
File chrome/browser/signin/screenlock_bridge.h (right):

https://codereview.chromium.org/446743003/diff/440001/chrome/browser/signin/s...
chrome/browser/signin/screenlock_bridge.h:92: size_t opacity_;
On 2014/08/12 18:09:47, xiyuan wrote:
> nit: document |opacity_| has range 0-100u.

Done.

https://codereview.chromium.org/446743003/diff/440001/chrome/browser/signin/s...
chrome/browser/signin/screenlock_bridge.h:94: scoped_ptr<base::string16>
tooltip_;
On 2014/08/12 18:09:47, xiyuan wrote:
> nit: Why use scoped_ptr for |tooltip_| and |icon_resource_url_|? It seems we
> don't need to differentiate NULL and empty string thus this is not necessary.

leftover from the initial cl version.

Done.

https://codereview.chromium.org/446743003/diff/440001/chrome/common/extension...
File chrome/common/extensions/api/easy_unlock_private.idl (right):

https://codereview.chromium.org/446743003/diff/440001/chrome/common/extension...
chrome/common/extensions/api/easy_unlock_private.idl:37: // A phone eligible to
unlock the devioce is detected, but it is not allowed
On 2014/08/12 18:09:47, xiyuan wrote:
> nit: devioce -> device

Done.

https://codereview.chromium.org/446743003/diff/440001/ui/login/account_picker...
File ui/login/account_picker/user_pod_template.html (right):

https://codereview.chromium.org/446743003/diff/440001/ui/login/account_picker...
ui/login/account_picker/user_pod_template.html:32: <div
class="custom-icon"></div>
On 2014/08/12 18:09:47, xiyuan wrote:
> nit: since we replaceChild, we only needs "custom-icon-container" here as an
> anchor.

Done.

[xiyuan, 2014-08-12 19:17:25]

lgtm

[dzhioev (left Google), 2014-08-12 19:36:09]

My comments for the part that I read so far:

https://codereview.chromium.org/446743003/diff/440001/chrome/browser/signin/e...
File chrome/browser/signin/easy_unlock_screenlock_state_handler.cc (right):

https://codereview.chromium.org/446743003/diff/440001/chrome/browser/signin/e...
chrome/browser/signin/easy_unlock_screenlock_state_handler.cc:98: state_ =
screenlock_bridge_->lock_handler() ? new_state : STATE_INACTIVE;
screenlock_bridge_->IsLocked()?

https://codereview.chromium.org/446743003/diff/440001/chrome/browser/signin/e...
chrome/browser/signin/easy_unlock_screenlock_state_handler.cc:98: state_ =
screenlock_bridge_->lock_handler() ? new_state : STATE_INACTIVE;
Why do you ignore state change when screen is unlocked?Doesn't it mean that when
user locks screen we need to wait for another call of ChangeState to enable easy
unlock? You could probably cache the state and then apply it in
OnScreenDidUnlock.

https://codereview.chromium.org/446743003/diff/440001/chrome/browser/signin/e...
chrome/browser/signin/easy_unlock_screenlock_state_handler.cc:102: if
(!screenlock_bridge_->lock_handler())
ditto

https://codereview.chromium.org/446743003/diff/440001/chrome/browser/signin/e...
File chrome/browser/signin/easy_unlock_service.cc (right):

https://codereview.chromium.org/446743003/diff/440001/chrome/browser/signin/e...
chrome/browser/signin/easy_unlock_service.cc:52:
ScreenlockBridge::GetAuthenticatedUserEmail(profile),
On 2014/08/12 18:09:47, xiyuan wrote:
> EasyUnlockService is created with profile. Authenticated user name might not
be
> there when this gets called. We probably should defer
> |screenlock_state_handler_| construction or make it get the user email when
> needed.
Confirm. Authenticated user name definitely is not set at this point on first
login. Moreover it is never set for any user type expect regular users. Probably
we shouldn't create service for such users at all, or choose another way to
obtain user_id.

https://codereview.chromium.org/446743003/diff/440001/chrome/browser/signin/e...
chrome/browser/signin/easy_unlock_service.cc:69: prefs::kEasyUnlockEnabled,
I can't find where this pref is used. Is it needed?

https://codereview.chromium.org/446743003/diff/440001/chrome/browser/ui/webui...
File chrome/browser/ui/webui/chromeos/login/signin_screen_handler.h (left):

https://codereview.chromium.org/446743003/diff/440001/chrome/browser/ui/webui...
chrome/browser/ui/webui/chromeos/login/signin_screen_handler.h:1: // Copyright
(c) 2013 The Chromium Authors. All rights reserved.
Sorry for silly question, but isn't "easy unlock" supposed to work only on lock
screen, i.e. for users that are already logged in session? If so, then why
SigninScreenHandler is used as ScreenlockBridge::LockHandler?
SigninScreenHandler works only for login screen, not lock screen.

[xiyuan, 2014-08-12 19:44:42]

https://codereview.chromium.org/446743003/diff/440001/chrome/browser/ui/webui...
File chrome/browser/ui/webui/chromeos/login/signin_screen_handler.h (left):

https://codereview.chromium.org/446743003/diff/440001/chrome/browser/ui/webui...
chrome/browser/ui/webui/chromeos/login/signin_screen_handler.h:1: // Copyright
(c) 2013 The Chromium Authors. All rights reserved.
On 2014/08/12 19:36:09, dzhioev wrote:
> Sorry for silly question, but isn't "easy unlock" supposed to work only on
lock
> screen, i.e. for users that are already logged in session? If so, then why
> SigninScreenHandler is used as ScreenlockBridge::LockHandler?
> SigninScreenHandler works only for login screen, not lock screen.

Think SigninScreenHandler is used for the webui lock screen as well. The account
picker screen is used as the lock UI.

[tbarzic, 2014-08-12 21:40:58]

https://codereview.chromium.org/446743003/diff/440001/chrome/browser/signin/e...
File chrome/browser/signin/easy_unlock_screenlock_state_handler.cc (right):

https://codereview.chromium.org/446743003/diff/440001/chrome/browser/signin/e...
chrome/browser/signin/easy_unlock_screenlock_state_handler.cc:98: state_ =
screenlock_bridge_->lock_handler() ? new_state : STATE_INACTIVE;
On 2014/08/12 19:36:08, dzhioev wrote:
> screenlock_bridge_->IsLocked()?

Done.

https://codereview.chromium.org/446743003/diff/440001/chrome/browser/signin/e...
chrome/browser/signin/easy_unlock_screenlock_state_handler.cc:98: state_ =
screenlock_bridge_->lock_handler() ? new_state : STATE_INACTIVE;
On 2014/08/12 19:36:08, dzhioev wrote:
> Why do you ignore state change when screen is unlocked?Doesn't it mean that
when
> user locks screen we need to wait for another call of ChangeState to enable
easy
> unlock? You could probably cache the state and then apply it in
> OnScreenDidUnlock.

Yes. And the app would call ChangeState when screen unlocks. But reapplying
cached state also sounds reasonable.

https://codereview.chromium.org/446743003/diff/440001/chrome/browser/signin/e...
chrome/browser/signin/easy_unlock_screenlock_state_handler.cc:102: if
(!screenlock_bridge_->lock_handler())
On 2014/08/12 19:36:08, dzhioev wrote:
> ditto

Done.

https://codereview.chromium.org/446743003/diff/440001/chrome/browser/signin/e...
File chrome/browser/signin/easy_unlock_service.cc (right):

https://codereview.chromium.org/446743003/diff/440001/chrome/browser/signin/e...
chrome/browser/signin/easy_unlock_service.cc:52:
ScreenlockBridge::GetAuthenticatedUserEmail(profile),
On 2014/08/12 19:36:09, dzhioev wrote:
> On 2014/08/12 18:09:47, xiyuan wrote:
> > EasyUnlockService is created with profile. Authenticated user name might not
> be
> > there when this gets called. We probably should defer
> > |screenlock_state_handler_| construction or make it get the user email when
> > needed.
> Confirm. Authenticated user name definitely is not set at this point on first
> login. Moreover it is never set for any user type expect regular users.
Probably
> we shouldn't create service for such users at all, or choose another way to
> obtain user_id.

OK, changed the app loading logic to allow the app only for regular users and
bound screenlock_state_handler_ lifetime to easy unlock app's (between LoadApp
and UnloadApp).

(AuthenticatesUserEmail should be set by the time extension system is
initialized, right?)

https://codereview.chromium.org/446743003/diff/440001/chrome/browser/signin/e...
chrome/browser/signin/easy_unlock_service.cc:69: prefs::kEasyUnlockEnabled,
On 2014/08/12 19:36:09, dzhioev wrote:
> I can't find where this pref is used. Is it needed?

I don't think it's currently used, but xiyuan is wiring some preferences for
easy unlock in a separate cl (I think the plan is to create another pref, that
holds a bit more data, but I'll leave it to him to remove this)

[xiyuan, 2014-08-12 21:51:49]

https://codereview.chromium.org/446743003/diff/520001/chrome/browser/signin/e...
File chrome/browser/signin/easy_unlock_service.cc (right):

https://codereview.chromium.org/446743003/diff/520001/chrome/browser/signin/e...
chrome/browser/signin/easy_unlock_service.cc:162:
ScreenlockBridge::GetAuthenticatedUserEmail(profile_),
I would prefer to what we have in PS24, where |screenlock_state_handler_| is
lazily created. Maybe add a DCHECK() to make sure user email is set.

Doing this feels easy to break because the extension system init and setup
authenticated user is unrelated. The order might change in the future.

[tbarzic, 2014-08-12 22:12:52]

https://codereview.chromium.org/446743003/diff/520001/chrome/browser/signin/e...
File chrome/browser/signin/easy_unlock_service.cc (right):

https://codereview.chromium.org/446743003/diff/520001/chrome/browser/signin/e...
chrome/browser/signin/easy_unlock_service.cc:162:
ScreenlockBridge::GetAuthenticatedUserEmail(profile_),
On 2014/08/12 21:51:49, xiyuan wrote:
> I would prefer to what we have in PS24, where |screenlock_state_handler_| is
> lazily created. Maybe add a DCHECK() to make sure user email is set.
> 
> Doing this feels easy to break because the extension system init and setup
> authenticated user is unrelated. The order might change in the future.

ok, reverting this back. I'll keep reset before UnloadApp (let me know if you'd
prefer to call ChangeState(STATE_INACTIVE) instead of reset).

[xiyuan, 2014-08-12 22:14:39]

https://codereview.chromium.org/446743003/diff/520001/chrome/browser/signin/e...
File chrome/browser/signin/easy_unlock_service.cc (right):

https://codereview.chromium.org/446743003/diff/520001/chrome/browser/signin/e...
chrome/browser/signin/easy_unlock_service.cc:162:
ScreenlockBridge::GetAuthenticatedUserEmail(profile_),
On 2014/08/12 22:12:52, tbarzic wrote:
> On 2014/08/12 21:51:49, xiyuan wrote:
> > I would prefer to what we have in PS24, where |screenlock_state_handler_| is
> > lazily created. Maybe add a DCHECK() to make sure user email is set.
> > 
> > Doing this feels easy to break because the extension system init and setup
> > authenticated user is unrelated. The order might change in the future.
> 
> ok, reverting this back. I'll keep reset before UnloadApp (let me know if
you'd
> prefer to call ChangeState(STATE_INACTIVE) instead of reset).

Sounds good.

[dzhioev (left Google), 2014-08-13 15:43:20]

https://codereview.chromium.org/446743003/diff/440001/chrome/browser/signin/e...
File chrome/browser/signin/easy_unlock_service.cc (right):

https://codereview.chromium.org/446743003/diff/440001/chrome/browser/signin/e...
chrome/browser/signin/easy_unlock_service.cc:52:
ScreenlockBridge::GetAuthenticatedUserEmail(profile),
On 2014/08/12 21:40:58, tbarzic wrote:
> On 2014/08/12 19:36:09, dzhioev wrote:
> > On 2014/08/12 18:09:47, xiyuan wrote:
> > > EasyUnlockService is created with profile. Authenticated user name might
not
> > be
> > > there when this gets called. We probably should defer
> > > |screenlock_state_handler_| construction or make it get the user email
when
> > > needed.
> > Confirm. Authenticated user name definitely is not set at this point on
first
> > login. Moreover it is never set for any user type expect regular users.
> Probably
> > we shouldn't create service for such users at all, or choose another way to
> > obtain user_id.
> 
> OK, changed the app loading logic to allow the app only for regular users and
> bound screenlock_state_handler_ lifetime to easy unlock app's (between LoadApp
> and UnloadApp).
> 
> (AuthenticatesUserEmail should be set by the time extension system is
> initialized, right?)

I'm not sure, but I would not rely on it.
Why do you use authenticated username in the first place? On CrOS reliable
source of user's email is a User object, which can be gotten from profile with
ProfileHelper::GetUserByProfile method.

https://codereview.chromium.org/446743003/diff/440001/chrome/browser/ui/webui...
File chrome/browser/ui/webui/chromeos/login/signin_screen_handler.h (left):

https://codereview.chromium.org/446743003/diff/440001/chrome/browser/ui/webui...
chrome/browser/ui/webui/chromeos/login/signin_screen_handler.h:1: // Copyright
(c) 2013 The Chromium Authors. All rights reserved.
On 2014/08/12 19:44:42, xiyuan wrote:
> On 2014/08/12 19:36:09, dzhioev wrote:
> > Sorry for silly question, but isn't "easy unlock" supposed to work only on
> lock
> > screen, i.e. for users that are already logged in session? If so, then why
> > SigninScreenHandler is used as ScreenlockBridge::LockHandler?
> > SigninScreenHandler works only for login screen, not lock screen.
> 
> Think SigninScreenHandler is used for the webui lock screen as well. The
account
> picker screen is used as the lock UI.
Yes, I missed that.

https://codereview.chromium.org/446743003/diff/580001/ui/login/account_picker...
File ui/login/account_picker/user_pod_template.html (right):

https://codereview.chromium.org/446743003/diff/580001/ui/login/account_picker...
ui/login/account_picker/user_pod_template.html:25: <img class="capslock-hint"
Can you please verify that easy unlock icon doesn't interfere with this
indicator. It is shown when Caps Lock is on.

[xiyuan, 2014-08-13 15:53:41]

https://codereview.chromium.org/446743003/diff/440001/chrome/browser/signin/e...
File chrome/browser/signin/easy_unlock_service.cc (right):

https://codereview.chromium.org/446743003/diff/440001/chrome/browser/signin/e...
chrome/browser/signin/easy_unlock_service.cc:52:
ScreenlockBridge::GetAuthenticatedUserEmail(profile),
On 2014/08/13 15:43:19, dzhioev wrote:
> Why do you use authenticated username in the first place? On CrOS reliable
> source of user's email is a User object, which can be gotten from profile with
> ProfileHelper::GetUserByProfile method.

Tony has changed to lazily create |screenlock_state_handler_| in last patch so
that it does not depends on the extension system. And when it is called,
everything should already be up and running.

Easy unlock is not chrome os specific and we might support that in desktop
Mirror as well. That's why we have ScreenlockBridge::GetAuthenticatedUserEmail
wrapper. If we should stick with User on ChromeOS, we can change the wrapper
impl.

https://codereview.chromium.org/446743003/diff/580001/ui/login/account_picker...
File ui/login/account_picker/user_pod_template.html (right):

https://codereview.chromium.org/446743003/diff/580001/ui/login/account_picker...
ui/login/account_picker/user_pod_template.html:25: <img class="capslock-hint"
On 2014/08/13 15:43:19, dzhioev wrote:
> Can you please verify that easy unlock icon doesn't interfere with this
> indicator. It is shown when Caps Lock is on.

fyi, Alt+Search would show the caps lock indicator.

Right now, it would show on the left side of the lock icon. The padding could
use some polishments but both icons are visible and not overlapping.

[tbarzic, 2014-08-13 17:51:23]

https://codereview.chromium.org/446743003/diff/580001/ui/login/account_picker...
File ui/login/account_picker/user_pod_template.html (right):

https://codereview.chromium.org/446743003/diff/580001/ui/login/account_picker...
ui/login/account_picker/user_pod_template.html:25: <img class="capslock-hint"
On 2014/08/13 15:53:41, xiyuan wrote:
> On 2014/08/13 15:43:19, dzhioev wrote:
> > Can you please verify that easy unlock icon doesn't interfere with this
> > indicator. It is shown when Caps Lock is on.
> 
> fyi, Alt+Search would show the caps lock indicator.
> 
> Right now, it would show on the left side of the lock icon. The padding could
> use some polishments but both icons are visible and not overlapping.

As xiyuan said, the caps lock icon is shown to the left of the lock icon.

[dzhioev (left Google), 2014-08-13 18:09:23]

On 2014/08/13 17:51:23, tbarzic wrote:
>
https://codereview.chromium.org/446743003/diff/580001/ui/login/account_picker...
> File ui/login/account_picker/user_pod_template.html (right):
> 
>
https://codereview.chromium.org/446743003/diff/580001/ui/login/account_picker...
> ui/login/account_picker/user_pod_template.html:25: <img class="capslock-hint"
> On 2014/08/13 15:53:41, xiyuan wrote:
> > On 2014/08/13 15:43:19, dzhioev wrote:
> > > Can you please verify that easy unlock icon doesn't interfere with this
> > > indicator. It is shown when Caps Lock is on.
> > 
> > fyi, Alt+Search would show the caps lock indicator.
> > 
> > Right now, it would show on the left side of the lock icon. The padding
could
> > use some polishments but both icons are visible and not overlapping.
> 
> As xiyuan said, the caps lock icon is shown to the left of the lock icon.

LGTM

[tbarzic, 2014-08-13 20:56:05]

+isherman for extension function histogram

And missing owner approval from rogerta for
chrome/browser/signin/screenlock_bridge

[Ilya Sherman, 2014-08-13 21:18:24]

histograms lgtm

[Roger Tawa OOO till Jul 10th, 2014-08-14 16:05:50]

rubber stamp lgtm for chrome/browser/signin

Please add per-file lines to chrome/browser/signin/OWNERS for screenlock_*

https://codereview.chromium.org/446743003/diff/620001/chrome/browser/signin/e...
File chrome/browser/signin/easy_unlock_screenlock_state_handler.h (right):

https://codereview.chromium.org/446743003/diff/620001/chrome/browser/signin/e...
chrome/browser/signin/easy_unlock_screenlock_state_handler.h:16: // Profle
specific class responsible for updating screenlock UI for the user
Profle --> Profile

[tbarzic, 2014-08-14 18:56:04]

https://codereview.chromium.org/446743003/diff/620001/chrome/browser/signin/e...
File chrome/browser/signin/easy_unlock_screenlock_state_handler.h (right):

https://codereview.chromium.org/446743003/diff/620001/chrome/browser/signin/e...
chrome/browser/signin/easy_unlock_screenlock_state_handler.h:16: // Profle
specific class responsible for updating screenlock UI for the user
On 2014/08/14 16:05:50, Roger Tawa wrote:
> Profle --> Profile

Done.

[tbarzic, 2014-08-14 18:56:11]

The CQ bit was checked by tbarzic@chromium.org

[commit-bot: I haz the power, 2014-08-14 18:57:33]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/tbarzic@chromium.org/446743003/680001

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

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

[commit-bot: I haz the power, 2014-08-15 04:41:11]

Committed patchset #35 (680001) as 289784