Convert sticky keys to a chromeos::EventRewriter phase.

Convert sticky keys to a chromeos::EventRewriter phase.

BUG=354035
TEST=unit_tests,ash_unittests,manual
R=sadrul@chromium.org,derat@chromium.org

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

[kpschoedel, 2014-04-28 20:30:02]

This is not ready for full review yet. I'm just looking for comment on the
interface between the sticky keys rewriting phase and the surrounding
chromeos::EventRewriter.

https://codereview.chromium.org/255033003/diff/1/ash/sticky_keys/sticky_keys_...
File ash/sticky_keys/sticky_keys_controller.cc (right):

https://codereview.chromium.org/255033003/diff/1/ash/sticky_keys/sticky_keys_...
ash/sticky_keys/sticky_keys_controller.cc:419: #if 0  // XXX
I want to pull the native post-processing up to chromeos::EventRewriter right
away, since it should be the same whether the event is changed by sticky keys or
by some other rewriting. This will also eliminate X11 from sticky keys rewriting
itself.

https://codereview.chromium.org/255033003/diff/1/ash/sticky_keys/sticky_keys_...
File ash/sticky_keys/sticky_keys_controller.h (left):

https://codereview.chromium.org/255033003/diff/1/ash/sticky_keys/sticky_keys_...
ash/sticky_keys/sticky_keys_controller.h:146: class StickyKeysHandlerDelegate {
This was used for testing the nested dispatch, so it's no longer necessary.

https://codereview.chromium.org/255033003/diff/1/ash/sticky_keys/sticky_keys_...
File ash/sticky_keys/sticky_keys_controller.h (right):

https://codereview.chromium.org/255033003/diff/1/ash/sticky_keys/sticky_keys_...
ash/sticky_keys/sticky_keys_controller.h:64: class ASH_EXPORT
StickyKeysController {
I think it would be cleaner to move the rewriting part over to join
chromeos::EventRewriter later, with the display part (StickyKeysOverlay)
remaining here in ash/sticky_keys.

https://codereview.chromium.org/255033003/diff/1/ash/sticky_keys/sticky_keys_...
ash/sticky_keys/sticky_keys_controller.h:78: // Handles keyboard event. Returns
an |EventRewriteStatus|:
The interface here for passing back the additional modifier-up events is
modelled after the ui::EventRewriter one, so that
EventRewriter::NextDispatchEvent() just calls
SitckyKeysController::NextDispatchEvent().

https://codereview.chromium.org/255033003/diff/1/chrome/browser/chromeos/even...
File chrome/browser/chromeos/events/event_rewriter.cc (right):

https://codereview.chromium.org/255033003/diff/1/chrome/browser/chromeos/even...
chrome/browser/chromeos/events/event_rewriter.cc:196: case ui::ET_MOUSE_PRESSED:
I have not plumbed sticky key handling into non-key events yet.

https://codereview.chromium.org/255033003/diff/1/chrome/browser/chromeos/even...
File chrome/browser/chromeos/events/event_rewriter.h (right):

https://codereview.chromium.org/255033003/diff/1/chrome/browser/chromeos/even...
chrome/browser/chromeos/events/event_rewriter.h:35: // Things that
keyboard-related rewriter phases can change about an Event.
Ignore this motion. I was considering using this in the interface, but can't.

[sadrul, 2014-04-28 20:38:27]

Can you remind me why we need to call into sticky-key rewriter from
chromeos::EventRewriter? (because in the current code, the rewriters work
independently, without having to call into one from the other)

[kpschoedel, 2014-04-28 20:57:27]

On 2014/04/28 20:38:27, sadrul wrote:
> Can you remind me why we need to call into sticky-key rewriter from
> chromeos::EventRewriter? (because in the current code, the rewriters work
> independently, without having to call into one from the other)

The first piece of chromeos::EventRewriter changes modifier keys according to
user prefs, so sticky keys has to come after that. The last two pieces of
chromeos::EventRewriter use the modifier flags (e.g. Alt+Up to Page Up) so they
have to come after sticky keys (this is currently broken).

[sadrul, 2014-04-28 21:03:21]

On 2014/04/28 20:57:27, kpschoedel wrote:
> On 2014/04/28 20:38:27, sadrul wrote:
> > Can you remind me why we need to call into sticky-key rewriter from
> > chromeos::EventRewriter? (because in the current code, the rewriters work
> > independently, without having to call into one from the other)
> 
> The first piece of chromeos::EventRewriter changes modifier keys according to
> user prefs, so sticky keys has to come after that. The last two pieces of
> chromeos::EventRewriter use the modifier flags (e.g. Alt+Up to Page Up) so
they
> have to come after sticky keys (this is currently broken).

I would like the conversion to EventRewriter preserve the current behaviour
(including the broken bits if necessary) without introducing regressions, and
then fix the issues that exist today separately in subsequent CLs. Would that
allow us to remove the sticky-key bits from chromeos::EventRewriter in this CL?

[kpschoedel, 2014-04-28 21:06:39]

On 2014/04/28 21:03:21, sadrul wrote:
 I would like the conversion to EventRewriter preserve the current behaviour
> (including the broken bits if necessary) without introducing regressions, and
> then fix the issues that exist today separately in subsequent CLs. Would that
> allow us to remove the sticky-key bits from chromeos::EventRewriter in this
CL?

No, because chromeos::EventRewriter touching modifiers (and so returning
EVENT_REWRITE_REWRITTEN) would stop the sticky keys rewriter from being called.

[kpschoedel, 2014-05-07 17:56:55]

https://codereview.chromium.org/255033003/diff/60001/ash/sticky_keys/sticky_k...
File ash/sticky_keys/sticky_keys_unittest.cc (left):

https://codereview.chromium.org/255033003/diff/60001/ash/sticky_keys/sticky_k...
ash/sticky_keys/sticky_keys_unittest.cc:806: TEST_F(StickyKeysTest,
KeyEventDispatchImpl) {
Moved to event_rewriter_unittest to satisfy dependency ordering.

[kpschoedel, 2014-05-20 17:05:43]

Sync with upstream (r271662 + review 270633012 tests)

[kpschoedel, 2014-06-05 21:27:46]

Updated to ToT, and collapsed the obsolete (rebase) patch sets for clarity.

[Daniel Erat, 2014-06-05 23:16:11]

lgtm

approving as an owner, but please wait for sadrul's review

https://codereview.chromium.org/255033003/diff/150001/ash/sticky_keys/sticky_...
File ash/sticky_keys/sticky_keys_controller.cc (right):

https://codereview.chromium.org/255033003/diff/150001/ash/sticky_keys/sticky_...
ash/sticky_keys/sticky_keys_controller.cc:132: return consumed ?
ui::EVENT_REWRITE_DISCARD
this looks like it's duplicated a few times. mind moving it into a helper
function in an anon namespace?

  if (consumed)
    return ui::EVENT_REWRITE_DISCARD;
  else if (mod_up_flags)
    return ...
  etc.

would probably be easier to read, too, even if it's a few more lines of code.

https://codereview.chromium.org/255033003/diff/150001/ash/sticky_keys/sticky_...
ash/sticky_keys/sticky_keys_controller.cc:379: return false;
what's the reason for this change? (just asking because i don't have much state
about this code and the description doesn't seem to mention it.)

https://codereview.chromium.org/255033003/diff/150001/ash/sticky_keys/sticky_...
File ash/sticky_keys/sticky_keys_controller.h (right):

https://codereview.chromium.org/255033003/diff/150001/ash/sticky_keys/sticky_...
ash/sticky_keys/sticky_keys_controller.h:237: // consumes the keyboard event
nit: add trailing period

https://codereview.chromium.org/255033003/diff/150001/ash/sticky_keys/sticky_...
ash/sticky_keys/sticky_keys_controller.h:244: // consumes the keyboard event
nit: add trailing period

https://codereview.chromium.org/255033003/diff/150001/ash/sticky_keys/sticky_...
File ash/sticky_keys/sticky_keys_unittest.cc (right):

https://codereview.chromium.org/255033003/diff/150001/ash/sticky_keys/sticky_...
ash/sticky_keys/sticky_keys_unittest.cc:126: ui::KeyEvent* event = new
ui::KeyEvent(type, code, 0, true);
nit: just return this directly instead of assigning it to a local variable

https://codereview.chromium.org/255033003/diff/150001/ash/sticky_keys/sticky_...
ash/sticky_keys/sticky_keys_unittest.cc:144: ui::MouseEvent*
GenerateSynthesizedMouseClickEvent(ui::EventType type,
nit: move first argument to its own line, indented four spaces

https://codereview.chromium.org/255033003/diff/150001/ash/sticky_keys/sticky_...
ash/sticky_keys/sticky_keys_unittest.cc:179: bool r =
handler->HandleKeyEvent(key_event, key_event.key_code(), down, up);
return this directly

https://codereview.chromium.org/255033003/diff/150001/ash/sticky_keys/sticky_...
ash/sticky_keys/sticky_keys_unittest.cc:234: // Making sure Shift up keyboard
event is avaialble.
nit: available

https://codereview.chromium.org/255033003/diff/150001/chrome/browser/chromeos...
File chrome/browser/chromeos/events/event_rewriter.h (right):

https://codereview.chromium.org/255033003/diff/150001/chrome/browser/chromeos...
chrome/browser/chromeos/events/event_rewriter.h:58:
EventRewriter(ash::StickyKeysController* sticky_keys_controller);
add 'explicit' and a comment describing whether ownership is passed to this
class (if it is, it should take a scoped_ptr instead)

looks from the test like it can be NULL; please document that as well

https://codereview.chromium.org/255033003/diff/150001/chrome/browser/chromeos...
chrome/browser/chromeos/events/event_rewriter.h:185: ash::StickyKeysController*
sticky_keys_controller_;
nit: add a comment describing ownership of this pointer

https://codereview.chromium.org/255033003/diff/150001/chrome/browser/chromeos...
File chrome/browser/chromeos/events/event_rewriter_unittest.cc (right):

https://codereview.chromium.org/255033003/diff/150001/chrome/browser/chromeos...
chrome/browser/chromeos/events/event_rewriter_unittest.cc:1478: EventRewriter
rewriter(0);
nit: s/0/NULL/

https://codereview.chromium.org/255033003/diff/150001/chrome/browser/chromeos...
chrome/browser/chromeos/events/event_rewriter_unittest.cc:1536:
ui::EventDispatchDetails details = SendEventToProcessor(event);
return the details directly

[kpschoedel, 2014-06-06 17:53:23]

https://codereview.chromium.org/255033003/diff/150001/ash/sticky_keys/sticky_...
File ash/sticky_keys/sticky_keys_controller.cc (right):

https://codereview.chromium.org/255033003/diff/150001/ash/sticky_keys/sticky_...
ash/sticky_keys/sticky_keys_controller.cc:132: return consumed ?
ui::EVENT_REWRITE_DISCARD
On 2014/06/05 23:16:10, Daniel Erat (OOO Jun 6-9) wrote:
> this looks like it's duplicated a few times. mind moving it into a helper
> function in an anon namespace?
> 
>   if (consumed)
>     return ui::EVENT_REWRITE_DISCARD;
>   else if (mod_up_flags)
>     return ...
>   etc.
> 
> would probably be easier to read, too, even if it's a few more lines of code.

Done.

https://codereview.chromium.org/255033003/diff/150001/ash/sticky_keys/sticky_...
ash/sticky_keys/sticky_keys_controller.cc:379: return false;
Short answer is that these functions are defined to return true if the event is
consumed, which isn't the case here.

https://codereview.chromium.org/255033003/diff/150001/ash/sticky_keys/sticky_...
File ash/sticky_keys/sticky_keys_controller.h (right):

https://codereview.chromium.org/255033003/diff/150001/ash/sticky_keys/sticky_...
ash/sticky_keys/sticky_keys_controller.h:237: // consumes the keyboard event
On 2014/06/05 23:16:10, Daniel Erat (OOO Jun 6-9) wrote:
> nit: add trailing period

Done.

https://codereview.chromium.org/255033003/diff/150001/ash/sticky_keys/sticky_...
ash/sticky_keys/sticky_keys_controller.h:244: // consumes the keyboard event
On 2014/06/05 23:16:10, Daniel Erat (OOO Jun 6-9) wrote:
> nit: add trailing period

Done.

https://codereview.chromium.org/255033003/diff/150001/ash/sticky_keys/sticky_...
File ash/sticky_keys/sticky_keys_unittest.cc (right):

https://codereview.chromium.org/255033003/diff/150001/ash/sticky_keys/sticky_...
ash/sticky_keys/sticky_keys_unittest.cc:126: ui::KeyEvent* event = new
ui::KeyEvent(type, code, 0, true);
On 2014/06/05 23:16:10, Daniel Erat (OOO Jun 6-9) wrote:
> nit: just return this directly instead of assigning it to a local variable

Done.

https://codereview.chromium.org/255033003/diff/150001/ash/sticky_keys/sticky_...
ash/sticky_keys/sticky_keys_unittest.cc:144: ui::MouseEvent*
GenerateSynthesizedMouseClickEvent(ui::EventType type,
On 2014/06/05 23:16:10, Daniel Erat (OOO Jun 6-9) wrote:
> nit: move first argument to its own line, indented four spaces

Done.

https://codereview.chromium.org/255033003/diff/150001/ash/sticky_keys/sticky_...
ash/sticky_keys/sticky_keys_unittest.cc:179: bool r =
handler->HandleKeyEvent(key_event, key_event.key_code(), down, up);
On 2014/06/05 23:16:10, Daniel Erat (OOO Jun 6-9) wrote:
> return this directly

Done.

https://codereview.chromium.org/255033003/diff/150001/ash/sticky_keys/sticky_...
ash/sticky_keys/sticky_keys_unittest.cc:234: // Making sure Shift up keyboard
event is avaialble.
On 2014/06/05 23:16:10, Daniel Erat (OOO Jun 6-9) wrote:
> nit: available

Done.

https://codereview.chromium.org/255033003/diff/150001/chrome/browser/chromeos...
File chrome/browser/chromeos/events/event_rewriter.h (right):

https://codereview.chromium.org/255033003/diff/150001/chrome/browser/chromeos...
chrome/browser/chromeos/events/event_rewriter.h:58:
EventRewriter(ash::StickyKeysController* sticky_keys_controller);
On 2014/06/05 23:16:10, Daniel Erat (OOO Jun 6-9) wrote:
> add 'explicit' and a comment describing whether ownership is passed to this
> class (if it is, it should take a scoped_ptr instead)
> 
> looks from the test like it can be NULL; please document that as well

Done.

Ideally this will be temporary and I can move the rewriting parts of sticky key
handling directly into the rewriter in a later CL.

https://codereview.chromium.org/255033003/diff/150001/chrome/browser/chromeos...
chrome/browser/chromeos/events/event_rewriter.h:185: ash::StickyKeysController*
sticky_keys_controller_;
On 2014/06/05 23:16:10, Daniel Erat (OOO Jun 6-9) wrote:
> nit: add a comment describing ownership of this pointer

Done.

https://codereview.chromium.org/255033003/diff/150001/chrome/browser/chromeos...
File chrome/browser/chromeos/events/event_rewriter_unittest.cc (right):

https://codereview.chromium.org/255033003/diff/150001/chrome/browser/chromeos...
chrome/browser/chromeos/events/event_rewriter_unittest.cc:1478: EventRewriter
rewriter(0);
On 2014/06/05 23:16:10, Daniel Erat (OOO Jun 6-9) wrote:
> nit: s/0/NULL/

Done.

https://codereview.chromium.org/255033003/diff/150001/chrome/browser/chromeos...
chrome/browser/chromeos/events/event_rewriter_unittest.cc:1536:
ui::EventDispatchDetails details = SendEventToProcessor(event);
On 2014/06/05 23:16:10, Daniel Erat (OOO Jun 6-9) wrote:
> return the details directly

Done (used to have debug logging in there).

[sadrul, 2014-06-16 15:07:43]

+tengs@ for sticky-keys changes.

LGTM

https://codereview.chromium.org/255033003/diff/170001/chrome/browser/chromeos...
File chrome/browser/chromeos/chrome_browser_main_chromeos.cc (left):

https://codereview.chromium.org/255033003/diff/170001/chrome/browser/chromeos...
chrome/browser/chromeos/chrome_browser_main_chromeos.cc:760:
data_promo_notification_.reset(new DataPromoNotification()),
whoa

https://codereview.chromium.org/255033003/diff/170001/chrome/browser/chromeos...
File chrome/browser/chromeos/chrome_browser_main_chromeos.cc (right):

https://codereview.chromium.org/255033003/diff/170001/chrome/browser/chromeos...
chrome/browser/chromeos/chrome_browser_main_chromeos.cc:761: new
EventRewriter(ash::Shell::GetInstance()->sticky_keys_controller())));
A quick explanation of why you are moving this down here?

https://codereview.chromium.org/255033003/diff/170001/chrome/browser/chromeos...
File chrome/browser/chromeos/events/event_rewriter.cc (right):

https://codereview.chromium.org/255033003/diff/170001/chrome/browser/chromeos...
chrome/browser/chromeos/events/event_rewriter.cc:366: status =
ui::EVENT_REWRITE_REWRITTEN;
Add a comment here why.

[kpschoedel, 2014-06-16 15:29:28]

https://codereview.chromium.org/255033003/diff/170001/chrome/browser/chromeos...
File chrome/browser/chromeos/chrome_browser_main_chromeos.cc (left):

https://codereview.chromium.org/255033003/diff/170001/chrome/browser/chromeos...
chrome/browser/chromeos/chrome_browser_main_chromeos.cc:760:
data_promo_notification_.reset(new DataPromoNotification()),
On 2014/06/16 15:07:43, sadrul wrote:
> whoa

Ah, yes. I assume Google style is to separate statements with a semicolon.

Some day I'll use the comma operator wherever possible just to freak out a
reviewer.

https://codereview.chromium.org/255033003/diff/170001/chrome/browser/chromeos...
File chrome/browser/chromeos/chrome_browser_main_chromeos.cc (right):

https://codereview.chromium.org/255033003/diff/170001/chrome/browser/chromeos...
chrome/browser/chromeos/chrome_browser_main_chromeos.cc:761: new
EventRewriter(ash::Shell::GetInstance()->sticky_keys_controller())));
On 2014/06/16 15:07:43, sadrul wrote:
> A quick explanation of why you are moving this down here?

They now depend on ash::Shell (for sticky keys).

Possibly a follow-up CL can move the rewriting components of sticky keys over
into chromeos::EventRewriter itself to avoid this initialization dance.

https://codereview.chromium.org/255033003/diff/170001/chrome/browser/chromeos...
File chrome/browser/chromeos/events/event_rewriter.cc (right):

https://codereview.chromium.org/255033003/diff/170001/chrome/browser/chromeos...
chrome/browser/chromeos/events/event_rewriter.cc:366: status =
ui::EVENT_REWRITE_REWRITTEN;
On 2014/06/16 15:07:43, sadrul wrote:
> Add a comment here why.

Done.

[Tim Song, 2014-06-16 18:32:24]

https://codereview.chromium.org/255033003/diff/210001/ash/sticky_keys/sticky_...
File ash/sticky_keys/sticky_keys_controller.cc (right):

https://codereview.chromium.org/255033003/diff/210001/ash/sticky_keys/sticky_...
ash/sticky_keys/sticky_keys_controller.cc:37: if (mod_up_flags)
It seems that |mod_up_flags| is only being used here and refers to modifier keys
being "unstuck". This is a bit confusing when |mod_down_flags| refers to
modifier flags that are set for the specific event being handled.

Why not just use a boolean that is true if any modifier key is released instead?

https://codereview.chromium.org/255033003/diff/210001/ash/sticky_keys/sticky_...
ash/sticky_keys/sticky_keys_controller.cc:181: return remaining ?
ui::EVENT_REWRITE_DISPATCH_ANOTHER
In the comments for this function in the header, it says this should return
ui::EVENT_REWRITE_CONTINUE when there are no pending key-up events. Shouldn't
you also check if new_event is NULL for this case?

https://codereview.chromium.org/255033003/diff/210001/ash/sticky_keys/sticky_...
File ash/sticky_keys/sticky_keys_controller.h (right):

https://codereview.chromium.org/255033003/diff/210001/ash/sticky_keys/sticky_...
ash/sticky_keys/sticky_keys_controller.h:82: //   according to the changes to
|state|;
What does |state| refer to here? The StickyKeyState of the modifier key
handlers? 

Also, please mention in the comments here that the rewritten modifier flags will
be written to the |flags| argument, which will remain unchanged except if
ui::EVENT_REWRITE_REWRITTEN or ui::EVENT_REWRITE_DISPATCH_ANOTHER is returned.

https://codereview.chromium.org/255033003/diff/210001/ash/sticky_keys/sticky_...
ash/sticky_keys/sticky_keys_controller.h:102: // - ui::EVENT_REWRITE_CONTINUE if
there are no pending modifier-up events.
Mention that |new_event| will be null in this case.

[kpschoedel, 2014-06-16 21:09:08]

https://codereview.chromium.org/255033003/diff/210001/ash/sticky_keys/sticky_...
File ash/sticky_keys/sticky_keys_controller.cc (right):

https://codereview.chromium.org/255033003/diff/210001/ash/sticky_keys/sticky_...
ash/sticky_keys/sticky_keys_controller.cc:37: if (mod_up_flags)
On 2014/06/16 18:32:23, Tim Song wrote:
> Why not just use a boolean that is true if any modifier key is released
instead?

In an earlier iteration the union of 'unstuck' modifiers was returned. I'll
replace this with a boolean.

https://codereview.chromium.org/255033003/diff/210001/ash/sticky_keys/sticky_...
ash/sticky_keys/sticky_keys_controller.cc:181: return remaining ?
ui::EVENT_REWRITE_DISPATCH_ANOTHER
On 2014/06/16 18:32:23, Tim Song wrote:
> In the comments for this function in the header, it says this should return
> ui::EVENT_REWRITE_CONTINUE when there are no pending key-up events. Shouldn't
> you also check if new_event is NULL for this case?

Done.

https://codereview.chromium.org/255033003/diff/210001/ash/sticky_keys/sticky_...
File ash/sticky_keys/sticky_keys_controller.h (right):

https://codereview.chromium.org/255033003/diff/210001/ash/sticky_keys/sticky_...
ash/sticky_keys/sticky_keys_controller.h:82: //   according to the changes to
|state|;
On 2014/06/16 18:32:24, Tim Song wrote:
> What does |state| refer to here? The StickyKeyState of the modifier key
> handlers? 

Should read |flags|; fixed.

> Also, please mention in the comments here that the rewritten modifier flags
will
> be written to the |flags| argument, which will remain unchanged except if
> ui::EVENT_REWRITE_REWRITTEN or ui::EVENT_REWRITE_DISPATCH_ANOTHER is returned.

Done.

https://codereview.chromium.org/255033003/diff/210001/ash/sticky_keys/sticky_...
ash/sticky_keys/sticky_keys_controller.h:102: // - ui::EVENT_REWRITE_CONTINUE if
there are no pending modifier-up events.
On 2014/06/16 18:32:23, Tim Song wrote:
> Mention that |new_event| will be null in this case.

Done (borrowing from the corresponding comment in ui/events/event_rewriter.h).

[Tim Song, 2014-06-16 21:37:05]

lgtm :)

[kpschoedel, 2014-06-16 21:37:22]

The CQ bit was checked by kpschoedel@chromium.org

[commit-bot: I haz the power, 2014-06-16 21:39:10]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/kpschoedel@chromium.org/255033003/250001

[commit-bot: I haz the power, 2014-06-17 04:10:41]

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

[commit-bot: I haz the power, 2014-06-17 04:10:42]

Try jobs failed on following builders:
  linux_chromium_chromeos_clang_dbg on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/linux_chromium_chrome...)

[kpschoedel, 2014-06-19 01:38:17]

The CQ bit was checked by kpschoedel@chromium.org

[commit-bot: I haz the power, 2014-06-19 01:39:25]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/kpschoedel@chromium.org/255033003/310001

[commit-bot: I haz the power, 2014-06-19 12:32:56]

Change committed as 278342

[kpschoedel, 2014-06-19 14:05:37]

A revert of this CL has been created in
https://codereview.chromium.org/343923002/ by kpschoedel@chromium.org.

The reason for reverting is:
http://build.chromium.org/p/chromium.memory.fyi/builders/Chromium%20OS%20%28v...

The change to chromeos::EventRewriter::RewriteEvent() leads to a ui::MouseEvent
object being used for a ui::MouseWheelEvent..

[kpschoedel, 2014-06-20 18:35:12]

The CQ bit was checked by kpschoedel@chromium.org

[commit-bot: I haz the power, 2014-06-20 19:03:39]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/kpschoedel@chromium.org/255033003/330001

[commit-bot: I haz the power, 2014-06-20 23:21:18]

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

[commit-bot: I haz the power, 2014-06-21 04:31:04]

Change committed as 278919