Move ClientSession's input logic into separate components.

This CL moves much of the input tracking logic out of ClientSession, which means:
* We can re-use existing client-side input pipeline components.
* Individual features of the input pipeline are isolated from one another.
* It'll be easier to move some portions of the pipeline into ChromotingHost, where they belong.

The CL makes the following changes:
* Moves KeyEventTracker to InputEventTracker and has it release mouse buttons as well as keys.
* Moves blocking of events when there is local input to a new RemoteInputFilter component.
* Simplifies ClientSession to enable/disable events by setting and clearing the output InputStub on an InputFilter.
* Simplifies ClientSession's SetDisableInputs() (used to temporarily disable inputs during the Continue dialog for IT2Me) to use the InputFilter mechanism.
* Releases keys and buttons when entering the input-blocking state.

BUG=118511
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=130263

[Wez, 2012-02-27 18:59:03]

Fix for the Chromoting Host suppressing repeated key-down events received from
clients.

I plan to follow-up with a couple of CLs to move bits of the input pipeline
logic out of ClientSession.

http://codereview.chromium.org/9465035/diff/1/remoting/host/client_session.cc
File remoting/host/client_session.cc (left):

http://codereview.chromium.org/9465035/diff/1/remoting/host/client_session.cc...
remoting/host/client_session.cc:205: (pressed_keys_.find(event.keycode()) ==
pressed_keys_.end());
Removing this actually fixes the client-side repeat suppression issue.

[Jamie, 2012-02-27 19:39:13]

lgtm as worthwhile clean-up, but I don't understand how it fixes the key-repeat
problem.

http://codereview.chromium.org/9465035/diff/1/remoting/host/client_session.cc
File remoting/host/client_session.cc (left):

http://codereview.chromium.org/9465035/diff/1/remoting/host/client_session.cc...
remoting/host/client_session.cc:205: (pressed_keys_.find(event.keycode()) ==
pressed_keys_.end());
On 2012/02/27 18:59:04, Wez wrote:
> Removing this actually fixes the client-side repeat suppression issue.

How? This code only runs if the continue dialog is visible.

[Wez, 2012-02-27 20:01:20]

http://codereview.chromium.org/9465035/diff/1/remoting/host/client_session.cc
File remoting/host/client_session.cc (left):

http://codereview.chromium.org/9465035/diff/1/remoting/host/client_session.cc...
remoting/host/client_session.cc:205: (pressed_keys_.find(event.keycode()) ==
pressed_keys_.end());
On 2012/02/27 19:39:14, Jamie wrote:
> On 2012/02/27 18:59:04, Wez wrote:
> > Removing this actually fixes the client-side repeat suppression issue.
> 
> How? This code only runs if the continue dialog is visible.

You're right; confused myself by splitting the fix from the cleanup.  Actually,
this CL needs a little more work so let's go with the existing fix as-is and
I'll tidy this up for re-submission.

[Wez, 2012-03-08 02:11:49]

On 2012/02/27 20:01:20, Wez wrote:
> http://codereview.chromium.org/9465035/diff/1/remoting/host/client_session.cc
> File remoting/host/client_session.cc (left):
> 
>
http://codereview.chromium.org/9465035/diff/1/remoting/host/client_session.cc...
> remoting/host/client_session.cc:205: (pressed_keys_.find(event.keycode()) ==
> pressed_keys_.end());
> On 2012/02/27 19:39:14, Jamie wrote:
> > On 2012/02/27 18:59:04, Wez wrote:
> > > Removing this actually fixes the client-side repeat suppression issue.
> > 
> > How? This code only runs if the continue dialog is visible.
> 
> You're right; confused myself by splitting the fix from the cleanup. 
Actually,
> this CL needs a little more work so let's go with the existing fix as-is and
> I'll tidy this up for re-submission.

I've revised this cleanup a little, and made a few changes:

* Replaced the ClientSession's "authenticated" and "awaiting-continue" flags
with a single disable-inputs flag, set initially and cleared upon
authentication.
* Disable all remote input events when the local user moves the mouse, not just
mouse events.
* Release keyboard and mouse buttons when the disable-inputs flag becomes set
via ChromotingHost::Pause().

This version has an issue with the filtering of events when local input occurs,
because I've taken out the special-case for allowing key release events through,
and I've not yet made remote keys & buttons get released when we enter
local-input mode.

[Wez, 2012-03-15 01:43:15]

On 2012/03/08 02:11:49, Wez wrote:
> On 2012/02/27 20:01:20, Wez wrote:
> >
http://codereview.chromium.org/9465035/diff/1/remoting/host/client_session.cc
> > File remoting/host/client_session.cc (left):
> > 
> >
>
http://codereview.chromium.org/9465035/diff/1/remoting/host/client_session.cc...
> > remoting/host/client_session.cc:205: (pressed_keys_.find(event.keycode()) ==
> > pressed_keys_.end());
> > On 2012/02/27 19:39:14, Jamie wrote:
> > > On 2012/02/27 18:59:04, Wez wrote:
> > > > Removing this actually fixes the client-side repeat suppression issue.
> > > 
> > > How? This code only runs if the continue dialog is visible.
> > 
> > You're right; confused myself by splitting the fix from the cleanup. 
> Actually,
> > this CL needs a little more work so let's go with the existing fix as-is and
> > I'll tidy this up for re-submission.
> 
> I've revised this cleanup a little, and made a few changes:
> 
> * Replaced the ClientSession's "authenticated" and "awaiting-continue" flags
> with a single disable-inputs flag, set initially and cleared upon
> authentication.
> * Disable all remote input events when the local user moves the mouse, not
just
> mouse events.
> * Release keyboard and mouse buttons when the disable-inputs flag becomes set
> via ChromotingHost::Pause().
> 
> This version has an issue with the filtering of events when local input
occurs,
> because I've taken out the special-case for allowing key release events
through,
> and I've not yet made remote keys & buttons get released when we enter
> local-input mode.

This version moves the filtering of local inputs out to a new component, and
releases buttons & keys when entering the filtering state.

PTAL!

[Jamie, 2012-03-15 18:38:56]

lgtm with a couple of nits and some bigger concerns that can be follow-up CLs.

http://codereview.chromium.org/9465035/diff/7001/remoting/host/client_session.cc
File remoting/host/client_session.cc (right):

http://codereview.chromium.org/9465035/diff/7001/remoting/host/client_session...
remoting/host/client_session.cc:143: // SetDisableInputs(true) implicitly
restores the input event state.
Are you talking about modifier keys here? This comment isn't clear. Why not just
call ReleaseAll? It feels odd to be disabling inputs on disconnect since you
won't get any after that point.

http://codereview.chromium.org/9465035/diff/7001/remoting/host/client_session.h
File remoting/host/client_session.h (right):

http://codereview.chromium.org/9465035/diff/7001/remoting/host/client_session...
remoting/host/client_session.h:108: friend class
ClientSessionTest_RestoreEventState_Test;
Should this be the appropriate ALL_PREFIXES macro?

http://codereview.chromium.org/9465035/diff/10001/remoting/host/client_sessio...
File remoting/host/client_session.cc (right):

http://codereview.chromium.org/9465035/diff/10001/remoting/host/client_sessio...
remoting/host/client_session.cc:187: return false;
Presumably you could get rid of ShouldIgnoreInput altogether if the local input
monitor disconnected the input_filter instead of setting
|latest_local_input_time_|. That's fine as a follow-up CL though.

http://codereview.chromium.org/9465035/diff/10001/remoting/protocol/input_eve...
File remoting/protocol/input_event_tracker.cc (right):

http://codereview.chromium.org/9465035/diff/10001/remoting/protocol/input_eve...
remoting/protocol/input_event_tracker.cc:24: DCHECK(event.has_keycode());
Since this event comes from a remote source, I think the check should be more
rigourous than a DCHECK, which won't do anything in a release build. Closing the
connection is probably the right thing to do, but failing that, we should ignore
the event. It can be a separate CL though, and InputFilter might be a better
place for it (or even a separate InputValidator).

http://codereview.chromium.org/9465035/diff/10001/remoting/protocol/input_eve...
remoting/protocol/input_event_tracker.cc:66: // using the current cursor
position, and we wouldn't set position here.
I don't think I agree with this. Having the input sanitization in one
cross-platform place is a good thing, surely? Whether or not this is that place
is another question, but I don't think the EventInjectors should have to cope
with it.

http://codereview.chromium.org/9465035/diff/10001/remoting/protocol/input_eve...
File remoting/protocol/input_event_tracker_unittest.cc (right):

http://codereview.chromium.org/9465035/diff/10001/remoting/protocol/input_eve...
remoting/protocol/input_event_tracker_unittest.cc:44:
TEST(InputEventTrackerTest, NothingToRelease) {
Since this is now testing a class that deals with mouse events as well as
keyboard, can you add some tests for that? Follow-up CL is fine.

http://codereview.chromium.org/9465035/diff/12001/remoting/host/remote_input_...
File remoting/host/remote_input_filter.h (right):

http://codereview.chromium.org/9465035/diff/12001/remoting/host/remote_input_...
remoting/host/remote_input_filter.h:30: // local, and block remote input for a
short while.
You might want to re-read this comment :)

http://codereview.chromium.org/9465035/diff/12001/remoting/host/remote_input_...
remoting/host/remote_input_filter.h:42: // Queue of recently-injected mouse
positions used to distinguish echos of
s/echos/echoes/

http://codereview.chromium.org/9465035/diff/12001/remoting/host/remote_input_...
File remoting/host/remote_input_filter_unittest.cc (right):

http://codereview.chromium.org/9465035/diff/12001/remoting/host/remote_input_...
remoting/host/remote_input_filter_unittest.cc:62: TEST(MouseInputFilterTest,
LocalEchosOfRemoteActivity) {
s/Echos/Echoes/g :)

http://codereview.chromium.org/9465035/diff/12001/remoting/host/remote_input_...
remoting/host/remote_input_filter_unittest.cc:88: }
I think you need another InjectMouseEvent here.

[Wez, 2012-03-15 22:25:29]

http://codereview.chromium.org/9465035/diff/7001/remoting/host/client_session.cc
File remoting/host/client_session.cc (right):

http://codereview.chromium.org/9465035/diff/7001/remoting/host/client_session...
remoting/host/client_session.cc:143: // SetDisableInputs(true) implicitly
restores the input event state.
On 2012/03/15 18:38:56, Jamie wrote:
> Are you talking about modifier keys here? This comment isn't clear. Why not
just
> call ReleaseAll? It feels odd to be disabling inputs on disconnect since you
> won't get any after that point.

In principle no, we won't.  This is host-side code, and after Disconnect() the
ClientSession should not inject further events, so I'd prefer to keep this extra
protection.

I've tweaked the comment wording to be clearer.

http://codereview.chromium.org/9465035/diff/7001/remoting/host/client_session.h
File remoting/host/client_session.h (right):

http://codereview.chromium.org/9465035/diff/7001/remoting/host/client_session...
remoting/host/client_session.h:108: friend class
ClientSessionTest_RestoreEventState_Test;
On 2012/03/15 18:38:56, Jamie wrote:
> Should this be the appropriate ALL_PREFIXES macro?

Actually, I don't think it's required at all.  Removed.

http://codereview.chromium.org/9465035/diff/10001/remoting/host/client_sessio...
File remoting/host/client_session.cc (right):

http://codereview.chromium.org/9465035/diff/10001/remoting/host/client_sessio...
remoting/host/client_session.cc:187: return false;
On 2012/03/15 18:38:56, Jamie wrote:
> Presumably you could get rid of ShouldIgnoreInput altogether if the local
input
> monitor disconnected the input_filter instead of setting
> |latest_local_input_time_|. That's fine as a follow-up CL though.

This moved into RemoteInputFilter.

http://codereview.chromium.org/9465035/diff/10001/remoting/protocol/input_eve...
File remoting/protocol/input_event_tracker.cc (right):

http://codereview.chromium.org/9465035/diff/10001/remoting/protocol/input_eve...
remoting/protocol/input_event_tracker.cc:24: DCHECK(event.has_keycode());
On 2012/03/15 18:38:56, Jamie wrote:
> Since this event comes from a remote source, I think the check should be more
> rigourous than a DCHECK, which won't do anything in a release build. Closing
the
> connection is probably the right thing to do, but failing that, we should
ignore
> the event. It can be a separate CL though, and InputFilter might be a better
> place for it (or even a separate InputValidator).

Good spot.

I prefer to test for fields where they are used, rather than relying on
pre-filtering.  Will address this in a follow-up CL.

http://codereview.chromium.org/9465035/diff/10001/remoting/protocol/input_eve...
remoting/protocol/input_event_tracker.cc:66: // using the current cursor
position, and we wouldn't set position here.
On 2012/03/15 18:38:56, Jamie wrote:
> I don't think I agree with this. Having the input sanitization in one
> cross-platform place is a good thing, surely? Whether or not this is that
place
> is another question, but I don't think the EventInjectors should have to cope
> with it.

This isn't input sanitization.  When a client disconnects with buttons down, or
the host-side blocks remote inputs, we release buttons.  This code forces us to
release them at the position of the last remote movememnt, rather than wherever
the cursor is locally.

We do this to work around the platform-specific code having a vaguely-specified
requirement for positional fields, which is detail specific to the EventInjector
implementations.  "Sanitizing" events elsewhere, it's not clear what constitutes
a "sane" event.

http://codereview.chromium.org/9465035/diff/10001/remoting/protocol/input_eve...
File remoting/protocol/input_event_tracker_unittest.cc (right):

http://codereview.chromium.org/9465035/diff/10001/remoting/protocol/input_eve...
remoting/protocol/input_event_tracker_unittest.cc:44:
TEST(InputEventTrackerTest, NothingToRelease) {
On 2012/03/15 18:38:56, Jamie wrote:
> Since this is now testing a class that deals with mouse events as well as
> keyboard, can you add some tests for that? Follow-up CL is fine.

Done.

http://codereview.chromium.org/9465035/diff/12001/remoting/host/remote_input_...
File remoting/host/remote_input_filter.h (right):

http://codereview.chromium.org/9465035/diff/12001/remoting/host/remote_input_...
remoting/host/remote_input_filter.h:30: // local, and block remote input for a
short while.
On 2012/03/15 18:38:56, Jamie wrote:
> You might want to re-read this comment :)

Done.

http://codereview.chromium.org/9465035/diff/12001/remoting/host/remote_input_...
remoting/host/remote_input_filter.h:42: // Queue of recently-injected mouse
positions used to distinguish echos of
On 2012/03/15 18:38:56, Jamie wrote:
> s/echos/echoes/

Done.

http://codereview.chromium.org/9465035/diff/12001/remoting/host/remote_input_...
File remoting/host/remote_input_filter_unittest.cc (right):

http://codereview.chromium.org/9465035/diff/12001/remoting/host/remote_input_...
remoting/host/remote_input_filter_unittest.cc:62: TEST(MouseInputFilterTest,
LocalEchosOfRemoteActivity) {
On 2012/03/15 18:38:56, Jamie wrote:
> s/Echos/Echoes/g :)

Done.

http://codereview.chromium.org/9465035/diff/12001/remoting/host/remote_input_...
remoting/host/remote_input_filter_unittest.cc:88: }
On 2012/03/15 18:38:56, Jamie wrote:
> I think you need another InjectMouseEvent here.

Nope; the number of events being injected was intended to be 10, to match the
preceding test, which is also wrong.  The test wasn't being run because of a
mistake in the gyp edit. :-/

[commit-bot: I haz the power, 2012-03-15 22:44:42]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/wez@chromium.org/9465035/17005

[commit-bot: I haz the power, 2012-03-16 02:27:34]

Try job failure for 9465035-17005 (retry) on win_rel for steps "ui_tests,
browser_tests" (clobber build).
It's a second try, previously, step "compile" failed.
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=win_rel&nu...

[commit-bot: I haz the power, 2012-03-16 02:56:13]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/wez@chromium.org/9465035/17005

[commit-bot: I haz the power, 2012-03-16 02:56:29]

Failed to request the patch to try. Please note that binary filesare still
unsupported at the moment, this is being worked on.

Thanks for your patience.

HTTP Error 500: 
<html><head>
<meta http-equiv="content-type" content="text/html;charset=utf-8">
<title>500 Server Error</title>
</head>
<body text=#000000 bgcolor=#ffffff>
<h1>Error: Server Error</h1>
<h2>The server encountered an error and could not complete your request.<p>If
the problem persists, please <A
HREF="http://code.google.com/appengine/community.html">report</A> your problem
and mention this error message and the query that caused it.</h2>
<h2></h2>
</body></html>

[commit-bot: I haz the power, 2012-03-16 03:48:58]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/wez@chromium.org/9465035/17005

[commit-bot: I haz the power, 2012-03-18 04:39:57]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/wez@chromium.org/9465035/17005

[commit-bot: I haz the power, 2012-03-18 04:40:00]

Can't apply patch for file remoting/host/client_session.cc.
While running patch -p1 --forward --force;
patching file remoting/host/client_session.cc
Hunk #2 FAILED at 23.
Hunk #3 FAILED at 42.
Hunk #4 succeeded at 139 (offset 10 lines).
Hunk #5 FAILED at 140.
3 out of 5 hunks FAILED -- saving rejects to file
remoting/host/client_session.cc.rej

[Wez, 2012-03-29 22:00:29]

sergeyu: Amongst other things, this CL moves responsibility for blocking input
based on authentication, or the session being paused, to InputFilters; a
follow-up CL will remove the need for ClientSession to implement InputStub
itself. Let me know what you think!

[Sergey Ulanov, 2012-03-30 20:33:54]

LGTM with nits

http://codereview.chromium.org/9465035/diff/30001/remoting/host/remote_input_...
File remoting/host/remote_input_filter.cc (right):

http://codereview.chromium.org/9465035/diff/30001/remoting/host/remote_input_...
remoting/host/remote_input_filter.cc:24: } // namespace anonymous
nit: two spaces before //
should be "// namespace", without anonymous

http://codereview.chromium.org/9465035/diff/30001/remoting/host/remote_input_...
remoting/host/remote_input_filter.cc:82: .InMilliseconds();
nit: this line should be indented 4 characters.
Also I think it's more common to put dot to the previous line.

http://codereview.chromium.org/9465035/diff/30001/remoting/host/remote_input_...
File remoting/host/remote_input_filter.h (right):

http://codereview.chromium.org/9465035/diff/30001/remoting/host/remote_input_...
remoting/host/remote_input_filter.h:25:
RemoteInputFilter(protocol::InputEventTracker* event_tracker);
explicit

http://codereview.chromium.org/9465035/diff/30001/remoting/host/remote_input_...
File remoting/host/remote_input_filter_unittest.cc (right):

http://codereview.chromium.org/9465035/diff/30001/remoting/host/remote_input_...
remoting/host/remote_input_filter_unittest.cc:55: for (int i=0; i<10; ++i)
nit: add spaces around = and < here and in other tests.

http://codereview.chromium.org/9465035/diff/30001/remoting/protocol/input_eve...
File remoting/protocol/input_event_tracker.cc (right):

http://codereview.chromium.org/9465035/diff/30001/remoting/protocol/input_eve...
remoting/protocol/input_event_tracker.cc:61: for (int i = 1; i <
MouseEvent::BUTTON_MAX; i++) {
nit: might be cleaner to replace 1 with "MosueButton::BUTTON_UNDEFINED + 1".
Otherwise it's not clear where 1 comes from.

http://codereview.chromium.org/9465035/diff/30001/remoting/protocol/input_eve...
File remoting/protocol/input_event_tracker.h (right):

http://codereview.chromium.org/9465035/diff/30001/remoting/protocol/input_eve...
remoting/protocol/input_event_tracker.h:23:
InputEventTracker(protocol::InputStub* input_stub);
explicit

http://codereview.chromium.org/9465035/diff/30001/remoting/protocol/input_eve...
File remoting/protocol/input_event_tracker_unittest.cc (right):

http://codereview.chromium.org/9465035/diff/30001/remoting/protocol/input_eve...
remoting/protocol/input_event_tracker_unittest.cc:117:
InjectMouseEvent(EqualsMouseEvent(1, 1, BUTTON_RIGHT, false)))
nit: alight this line with (

[Lambros, 2012-03-30 23:31:11]

http://codereview.chromium.org/9465035/diff/30001/remoting/host/remote_input_...
File remoting/host/remote_input_filter.cc (right):

http://codereview.chromium.org/9465035/diff/30001/remoting/host/remote_input_...
remoting/host/remote_input_filter.cc:82: .InMilliseconds();
On 2012/03/30 20:33:54, sergeyu wrote:
> nit: this line should be indented 4 characters.
> Also I think it's more common to put dot to the previous line.
Drive-by: Consider using TimeDelta for this?

[Wez, 2012-04-01 00:47:15]

Have also fixed a couple of other missing 'explicit' prefixes in the InputStub
implementations.

http://codereview.chromium.org/9465035/diff/30001/remoting/host/remote_input_...
File remoting/host/remote_input_filter.cc (right):

http://codereview.chromium.org/9465035/diff/30001/remoting/host/remote_input_...
remoting/host/remote_input_filter.cc:24: } // namespace anonymous
On 2012/03/30 20:33:54, sergeyu wrote:
> nit: two spaces before //
> should be "// namespace", without anonymous

Done.

http://codereview.chromium.org/9465035/diff/30001/remoting/host/remote_input_...
remoting/host/remote_input_filter.cc:82: .InMilliseconds();
On 2012/03/30 20:33:54, sergeyu wrote:
> nit: this line should be indented 4 characters.
> Also I think it's more common to put dot to the previous line.

Done.

http://codereview.chromium.org/9465035/diff/30001/remoting/host/remote_input_...
remoting/host/remote_input_filter.cc:82: .InMilliseconds();
On 2012/03/30 23:31:11, Lambros wrote:
> On 2012/03/30 20:33:54, sergeyu wrote:
> > nit: this line should be indented 4 characters.
> > Also I think it's more common to put dot to the previous line.
> Drive-by: Consider using TimeDelta for this?

Now() - latest should be a TimeDelta, so it's just a question of where to
convert between TimeDelta and milliseconds. This layout seems easiest to read.

http://codereview.chromium.org/9465035/diff/30001/remoting/host/remote_input_...
File remoting/host/remote_input_filter.h (right):

http://codereview.chromium.org/9465035/diff/30001/remoting/host/remote_input_...
remoting/host/remote_input_filter.h:25:
RemoteInputFilter(protocol::InputEventTracker* event_tracker);
On 2012/03/30 20:33:54, sergeyu wrote:
> explicit

Done.

http://codereview.chromium.org/9465035/diff/30001/remoting/host/remote_input_...
File remoting/host/remote_input_filter_unittest.cc (right):

http://codereview.chromium.org/9465035/diff/30001/remoting/host/remote_input_...
remoting/host/remote_input_filter_unittest.cc:55: for (int i=0; i<10; ++i)
On 2012/03/30 20:33:54, sergeyu wrote:
> nit: add spaces around = and < here and in other tests.

Done.

http://codereview.chromium.org/9465035/diff/30001/remoting/protocol/input_eve...
File remoting/protocol/input_event_tracker.cc (right):

http://codereview.chromium.org/9465035/diff/30001/remoting/protocol/input_eve...
remoting/protocol/input_event_tracker.cc:61: for (int i = 1; i <
MouseEvent::BUTTON_MAX; i++) {
On 2012/03/30 20:33:54, sergeyu wrote:
> nit: might be cleaner to replace 1 with "MosueButton::BUTTON_UNDEFINED + 1".
> Otherwise it's not clear where 1 comes from.

Done.

http://codereview.chromium.org/9465035/diff/30001/remoting/protocol/input_eve...
File remoting/protocol/input_event_tracker.h (right):

http://codereview.chromium.org/9465035/diff/30001/remoting/protocol/input_eve...
remoting/protocol/input_event_tracker.h:23:
InputEventTracker(protocol::InputStub* input_stub);
On 2012/03/30 20:33:54, sergeyu wrote:
> explicit

Done.

http://codereview.chromium.org/9465035/diff/30001/remoting/protocol/input_eve...
File remoting/protocol/input_event_tracker_unittest.cc (right):

http://codereview.chromium.org/9465035/diff/30001/remoting/protocol/input_eve...
remoting/protocol/input_event_tracker_unittest.cc:117:
InjectMouseEvent(EqualsMouseEvent(1, 1, BUTTON_RIGHT, false)))
On 2012/03/30 20:33:54, sergeyu wrote:
> nit: alight this line with (

Done.

[commit-bot: I haz the power, 2012-04-01 00:59:53]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/wez@chromium.org/9465035/39002

[commit-bot: I haz the power, 2012-04-01 01:29:45]

Try job failure for 9465035-39002 (retry) on linux_rel for step "compile"
(clobber build).
It's a second try, previously, step "compile" failed.
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=linux_rel&...

[commit-bot: I haz the power, 2012-04-01 03:08:17]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/wez@chromium.org/9465035/37007

[commit-bot: I haz the power, 2012-04-01 20:23:06]

Can't apply patch for file remoting/client/plugin/chromoting_instance.cc.
While running patch -p1 --forward --force;
patching file remoting/client/plugin/chromoting_instance.cc
Hunk #2 succeeded at 363 (offset 15 lines).
Hunk #3 succeeded at 403 (offset 15 lines).
Hunk #4 FAILED at 400.
1 out of 4 hunks FAILED -- saving rejects to file
remoting/client/plugin/chromoting_instance.cc.rej

[commit-bot: I haz the power, 2012-04-02 20:05:32]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/wez@chromium.org/9465035/38023

[commit-bot: I haz the power, 2012-04-03 00:56:20]

Change committed as 130263