[KeyEvent Mac] Move WebInputEventFactory into chromium.

[KeyEvent Mac] Move WebInputEventFactory into chromium.

There was an inconsistency on the Mac platform that the WebInputEventFactory
(old WebKit code) was being used. Other platforms have migrated to using
builders and it was weird for the Mac code path to have some code on one
side of the blink divide that others didn't. This change brings the Mac
platform inline with the others by moving the input event
factory from blink into chromium.

blink change: https://codereview.chromium.org/1335673002/

BUG=493833, 237267
Committed: https://crrev.com/8db5ca887d4560ed15bf5e6e2dce69dc85868f25
Cr-Commit-Position: refs/heads/master@{#348989}

Committed: https://crrev.com/5405b8306550f01b86204d45fad3360593b39001
Cr-Commit-Position: refs/heads/master@{#349157}

[dtapuska, 2015-09-10 14:48:29]

dtapuska@chromium.org changed reviewers:
+ asvitkine@chromium.org, phajdan.jr@chromium.org, sadrul@chromium.org,
wez@chromium.org

[dtapuska, 2015-09-10 15:26:57]

On 2015/09/10 14:48:48, dtapuska wrote:

Corresponding blink change review is found here:
https://codereview.chromium.org/1335673002/

[dtapuska, 2015-09-11 20:31:03]

On 2015/09/10 15:26:57, dtapuska wrote:
> On 2015/09/10 14:48:48, dtapuska wrote:
> 
> Corresponding blink change review is found here:
> https://codereview.chromium.org/1335673002/

Ping.

[Wez, 2015-09-11 20:34:13]

On 2015/09/11 20:31:03, dtapuska wrote:
> On 2015/09/10 15:26:57, dtapuska wrote:
> > On 2015/09/10 14:48:48, dtapuska wrote:
> > 
> > Corresponding blink change review is found here:
> > https://codereview.chromium.org/1335673002/
> 
> Ping.

nit: The CL description one-line doesn't mention Mac specifically, but this
seems to be a Mac-specific patch?  Also, consider linking the Blink CL in the
actual Chromium CL description (and vice versa!).

[Alexei Svitkine (slow), 2015-09-11 20:39:31]

The files being moved don't seem to follow Chromium coding convention. Given
they're moving to Chromium code, I would think we should convert them at the
same time.

(Can be done on this CL, so that the diffs can be kept via patchsets on the CL.)

[Alexei Svitkine (slow), 2015-09-11 20:42:11]

https://codereview.chromium.org/1331013004/diff/40001/content/browser/rendere...
File content/browser/renderer_host/input/web_input_event_builders_mac.mm
(right):

https://codereview.chromium.org/1331013004/diff/40001/content/browser/rendere...
content/browser/renderer_host/input/web_input_event_builders_mac.mm:33: #include
<ApplicationServices/ApplicationServices.h>
Should be an #import.

https://codereview.chromium.org/1331013004/diff/40001/content/browser/rendere...
content/browser/renderer_host/input/web_input_event_builders_mac.mm:43: #if
__MAC_OS_X_VERSION_MAX_ALLOWED == 1060
We have base/mac/sdk_forward_declarations.h for these. Use that instead.

Additionally, I think these days we're building against the 10.10 SDK, so a lot
of these are likely not needed anymore.

https://codereview.chromium.org/1331013004/diff/40001/content/browser/rendere...
content/browser/renderer_host/input/web_input_event_builders_mac.mm:560: bool
WebKeyboardEventBuilder::isSystemKeyEvent(
We should at least update naming conventions of these functions to use the
Chromium one (i.e. upper case letter).

[dtapuska, 2015-09-14 13:29:05]

On 2015/09/11 20:39:31, Alexei Svitkine wrote:
> The files being moved don't seem to follow Chromium coding convention. Given
> they're moving to Chromium code, I would think we should convert them at the
> same time.
> 
> (Can be done on this CL, so that the diffs can be kept via patchsets on the
CL.)

I imagined this request would come; I didn't know how much we wanted to keep of
the original code vs moving it to the convention for the repo. I will try to
address the code style issues today.

[dtapuska, 2015-09-14 14:50:30]

https://codereview.chromium.org/1331013004/diff/40001/content/browser/rendere...
File content/browser/renderer_host/input/web_input_event_builders_mac.mm
(right):

https://codereview.chromium.org/1331013004/diff/40001/content/browser/rendere...
content/browser/renderer_host/input/web_input_event_builders_mac.mm:33: #include
<ApplicationServices/ApplicationServices.h>
On 2015/09/11 20:42:10, Alexei Svitkine wrote:
> Should be an #import.

Done.

https://codereview.chromium.org/1331013004/diff/40001/content/browser/rendere...
content/browser/renderer_host/input/web_input_event_builders_mac.mm:43: #if
__MAC_OS_X_VERSION_MAX_ALLOWED == 1060
On 2015/09/11 20:42:10, Alexei Svitkine wrote:
> We have base/mac/sdk_forward_declarations.h for these. Use that instead.
> 
> Additionally, I think these days we're building against the 10.10 SDK, so a
lot
> of these are likely not needed anymore.

Done.

https://codereview.chromium.org/1331013004/diff/40001/content/browser/rendere...
content/browser/renderer_host/input/web_input_event_builders_mac.mm:560: bool
WebKeyboardEventBuilder::isSystemKeyEvent(
On 2015/09/11 20:42:10, Alexei Svitkine wrote:
> We should at least update naming conventions of these functions to use the
> Chromium one (i.e. upper case letter).

Done.

[Alexei Svitkine (slow), 2015-09-14 17:14:43]

https://codereview.chromium.org/1331013004/diff/60001/content/browser/rendere...
File
content/browser/renderer_host/input/web_input_event_builders_mac_unittest.mm
(right):

https://codereview.chromium.org/1331013004/diff/60001/content/browser/rendere...
content/browser/renderer_host/input/web_input_event_builders_mac_unittest.mm:1:
// Copyright (c) 2015 The Chromium Authors. All rights reserved.
No (c)

https://codereview.chromium.org/1331013004/diff/60001/content/browser/rendere...
content/browser/renderer_host/input/web_input_event_builders_mac_unittest.mm:6:
#include <gtest/gtest.h>
Can this be #include "testing/gtest/include/gtest/gtest.h" instead?

https://codereview.chromium.org/1331013004/diff/60001/content/browser/rendere...
content/browser/renderer_host/input/web_input_event_builders_mac_unittest.mm:8:
#include "content/browser/renderer_host/input/web_input_event_builders_mac.h"
This should be the first include.

https://codereview.chromium.org/1331013004/diff/60001/ui/events/keycodes/keyb...
File ui/events/keycodes/keyboard_code_conversion_mac.mm (right):

https://codereview.chromium.org/1331013004/diff/60001/ui/events/keycodes/keyb...
ui/events/keycodes/keyboard_code_conversion_mac.mm:572: if
(!IsKeypadEvent(event) &&
Is this introducing a logic change? if so, it should probably be in a separate
CL.

[dtapuska, 2015-09-14 18:31:21]

https://codereview.chromium.org/1331013004/diff/60001/content/browser/rendere...
File
content/browser/renderer_host/input/web_input_event_builders_mac_unittest.mm
(right):

https://codereview.chromium.org/1331013004/diff/60001/content/browser/rendere...
content/browser/renderer_host/input/web_input_event_builders_mac_unittest.mm:1:
// Copyright (c) 2015 The Chromium Authors. All rights reserved.
On 2015/09/14 17:14:43, Alexei Svitkine wrote:
> No (c)

Done.

https://codereview.chromium.org/1331013004/diff/60001/content/browser/rendere...
content/browser/renderer_host/input/web_input_event_builders_mac_unittest.mm:6:
#include <gtest/gtest.h>
On 2015/09/14 17:14:43, Alexei Svitkine wrote:
> Can this be #include "testing/gtest/include/gtest/gtest.h" instead?

Done.

https://codereview.chromium.org/1331013004/diff/60001/content/browser/rendere...
content/browser/renderer_host/input/web_input_event_builders_mac_unittest.mm:8:
#include "content/browser/renderer_host/input/web_input_event_builders_mac.h"
On 2015/09/14 17:14:43, Alexei Svitkine wrote:
> This should be the first include.

Done.

https://codereview.chromium.org/1331013004/diff/60001/ui/events/keycodes/keyb...
File ui/events/keycodes/keyboard_code_conversion_mac.mm (right):

https://codereview.chromium.org/1331013004/diff/60001/ui/events/keycodes/keyb...
ui/events/keycodes/keyboard_code_conversion_mac.mm:572: if
(!IsKeypadEvent(event) &&
On 2015/09/14 17:14:43, Alexei Svitkine wrote:
> Is this introducing a logic change? if so, it should probably be in a separate
> CL.

Done.

[Alexei Svitkine (slow), 2015-09-14 18:54:03]

LGTM % remaining comments

https://codereview.chromium.org/1331013004/diff/80001/content/browser/rendere...
File content/browser/renderer_host/input/web_input_event_builders_mac.h (right):

https://codereview.chromium.org/1331013004/diff/80001/content/browser/rendere...
content/browser/renderer_host/input/web_input_event_builders_mac.h:14: #else
Hmm, this file isn't being included in any non-Objc files, so I'd just drop the
#ifdef altogether and it's else clause.

https://codereview.chromium.org/1331013004/diff/80001/content/browser/rendere...
content/browser/renderer_host/input/web_input_event_builders_mac.h:23: static
blink::WebKeyboardEvent Build(NSEvent*);
Nit: In Chromium code, keep the param names in the headers. Please fix all the
functions in this file.

https://codereview.chromium.org/1331013004/diff/80001/content/browser/rendere...
content/browser/renderer_host/input/web_input_event_builders_mac.h:35: bool
canRubberbandLeft,
Nit: can_rubberband_left same for the next param.

https://codereview.chromium.org/1331013004/diff/80001/content/browser/rendere...
File content/browser/renderer_host/input/web_input_event_builders_mac.mm
(right):

https://codereview.chromium.org/1331013004/diff/80001/content/browser/rendere...
content/browser/renderer_host/input/web_input_event_builders_mac.mm:34: #import
<AvailabilityMacros.h>
Nit: Is this needed anymore?

https://codereview.chromium.org/1331013004/diff/80001/content/browser/rendere...
content/browser/renderer_host/input/web_input_event_builders_mac.mm:51: //
function verifies that |targetKeyMask| and |otherKeyMask| (which should be
Nit: Update comment which still mentions the non hacker_style names.

[dtapuska, 2015-09-14 19:26:46]

https://codereview.chromium.org/1331013004/diff/80001/content/browser/rendere...
File content/browser/renderer_host/input/web_input_event_builders_mac.h (right):

https://codereview.chromium.org/1331013004/diff/80001/content/browser/rendere...
content/browser/renderer_host/input/web_input_event_builders_mac.h:14: #else
On 2015/09/14 18:54:03, Alexei Svitkine wrote:
> Hmm, this file isn't being included in any non-Objc files, so I'd just drop
the
> #ifdef altogether and it's else clause.

No this isn't possible the implementation mm file includes this file.

https://codereview.chromium.org/1331013004/diff/80001/content/browser/rendere...
content/browser/renderer_host/input/web_input_event_builders_mac.h:23: static
blink::WebKeyboardEvent Build(NSEvent*);
On 2015/09/14 18:54:03, Alexei Svitkine wrote:
> Nit: In Chromium code, keep the param names in the headers. Please fix all the
> functions in this file.

Done.

https://codereview.chromium.org/1331013004/diff/80001/content/browser/rendere...
content/browser/renderer_host/input/web_input_event_builders_mac.h:35: bool
canRubberbandLeft,
On 2015/09/14 18:54:03, Alexei Svitkine wrote:
> Nit: can_rubberband_left same for the next param.

Done.

https://codereview.chromium.org/1331013004/diff/80001/content/browser/rendere...
File content/browser/renderer_host/input/web_input_event_builders_mac.mm
(right):

https://codereview.chromium.org/1331013004/diff/80001/content/browser/rendere...
content/browser/renderer_host/input/web_input_event_builders_mac.mm:34: #import
<AvailabilityMacros.h>
On 2015/09/14 18:54:03, Alexei Svitkine wrote:
> Nit: Is this needed anymore?

Done.

https://codereview.chromium.org/1331013004/diff/80001/content/browser/rendere...
content/browser/renderer_host/input/web_input_event_builders_mac.mm:51: //
function verifies that |targetKeyMask| and |otherKeyMask| (which should be
On 2015/09/14 18:54:03, Alexei Svitkine wrote:
> Nit: Update comment which still mentions the non hacker_style names.

Done.

[Alexei Svitkine (slow), 2015-09-14 19:32:56]

https://codereview.chromium.org/1331013004/diff/80001/content/browser/rendere...
File content/browser/renderer_host/input/web_input_event_builders_mac.h (right):

https://codereview.chromium.org/1331013004/diff/80001/content/browser/rendere...
content/browser/renderer_host/input/web_input_event_builders_mac.h:14: #else
On 2015/09/14 19:26:46, dtapuska wrote:
> On 2015/09/14 18:54:03, Alexei Svitkine wrote:
> > Hmm, this file isn't being included in any non-Objc files, so I'd just drop
> the
> > #ifdef altogether and it's else clause.
> 
> No this isn't possible the implementation mm file includes this file.

My point is to only have:

@class NSEvent;
@class NSView;

Without the #else clause. Since all the includes of this header are in .mm files
(including its impl), they should all understand the @class syntax and there
shouldn't be any issues. Or am I missing something?

[dtapuska, 2015-09-14 19:39:29]

On 2015/09/14 19:32:56, Alexei Svitkine wrote:
>
https://codereview.chromium.org/1331013004/diff/80001/content/browser/rendere...
> File content/browser/renderer_host/input/web_input_event_builders_mac.h
(right):
> 
>
https://codereview.chromium.org/1331013004/diff/80001/content/browser/rendere...
> content/browser/renderer_host/input/web_input_event_builders_mac.h:14: #else
> On 2015/09/14 19:26:46, dtapuska wrote:
> > On 2015/09/14 18:54:03, Alexei Svitkine wrote:
> > > Hmm, this file isn't being included in any non-Objc files, so I'd just
drop
> > the
> > > #ifdef altogether and it's else clause.
> > 
> > No this isn't possible the implementation mm file includes this file.
> 
> My point is to only have:
> 
> @class NSEvent;
> @class NSView;
> 
> Without the #else clause. Since all the includes of this header are in .mm
files
> (including its impl), they should all understand the @class syntax and there
> shouldn't be any issues. Or am I missing something?

Yes you are correct; I mis-read the comment and thought you wanted the converse.

[dtapuska, 2015-09-14 19:40:07]

https://codereview.chromium.org/1331013004/diff/80001/content/browser/rendere...
File content/browser/renderer_host/input/web_input_event_builders_mac.h (right):

https://codereview.chromium.org/1331013004/diff/80001/content/browser/rendere...
content/browser/renderer_host/input/web_input_event_builders_mac.h:14: #else
On 2015/09/14 19:32:56, Alexei Svitkine wrote:
> On 2015/09/14 19:26:46, dtapuska wrote:
> > On 2015/09/14 18:54:03, Alexei Svitkine wrote:
> > > Hmm, this file isn't being included in any non-Objc files, so I'd just
drop
> > the
> > > #ifdef altogether and it's else clause.
> > 
> > No this isn't possible the implementation mm file includes this file.
> 
> My point is to only have:
> 
> @class NSEvent;
> @class NSView;
> 
> Without the #else clause. Since all the includes of this header are in .mm
files
> (including its impl), they should all understand the @class syntax and there
> shouldn't be any issues. Or am I missing something?

Done.

[dtapuska, 2015-09-15 13:51:49]

dtapuska@chromium.org changed reviewers:
+ mnaganov@chromium.org
- phajdan.jr@chromium.org

[mnaganov (inactive), 2015-09-15 17:29:01]

tools/copyright_scanner/third_party_files_whitelist.txt LGTM

[sadrul, 2015-09-15 18:18:52]

lgtm

[Alexei Svitkine (slow), 2015-09-15 18:39:58]

lgtm

[dtapuska, 2015-09-15 19:20:18]

The CQ bit was checked by dtapuska@chromium.org

[commit-bot: I haz the power, 2015-09-15 19:20:38]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1331013004/120001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1331013004/120001

[dtapuska, 2015-09-15 19:34:00]

dtapuska@chromium.org changed reviewers:
+ piman@chromium.org

[dtapuska, 2015-09-15 19:34:32]

On 2015/09/15 19:20:38, commit-bot: I haz the power wrote:
> CQ is trying da patch. Follow status at
>  https://chromium-cq-status.appspot.com/patch-status/1331013004/120001
> View timeline at
>  https://chromium-cq-status.appspot.com/patch-timeline/1331013004/120001

+piman for content/browser/DEPS

[piman, 2015-09-15 20:05:01]

lgtm

[commit-bot: I haz the power, 2015-09-15 20:56:16]

Committed patchset #7 (id:120001)

[commit-bot: I haz the power, 2015-09-15 20:57:29]

Patchset 7 (id:??) landed as
https://crrev.com/8db5ca887d4560ed15bf5e6e2dce69dc85868f25
Cr-Commit-Position: refs/heads/master@{#348989}

[Wez, 2015-09-15 23:25:35]

Much belated LGTM.

This is great - thanks for cleaning up!

https://codereview.chromium.org/1331013004/diff/40001/content/browser/DEPS
File content/browser/DEPS (left):

https://codereview.chromium.org/1331013004/diff/40001/content/browser/DEPS#ol...
content/browser/DEPS:89: # These should be burned down. http://crbug.com/237267
Include this bug # in the BUG= line?

https://codereview.chromium.org/1331013004/diff/120001/tools/copyright_scanne...
File tools/copyright_scanner/third_party_files_whitelist.txt (right):

https://codereview.chromium.org/1331013004/diff/120001/tools/copyright_scanne...
tools/copyright_scanner/third_party_files_whitelist.txt:55: # Copyright Apple,
Inc, Google Inc; BSD license. Not used on Android
nit: Missing . at end of comment.

[kochi, 2015-09-16 01:18:10]

A revert of this CL (patchset #7 id:120001) has been created in
https://codereview.chromium.org/1345043003/ by kochi@chromium.org.

The reason for reverting is: This caused compile failure on MacOSX 10.9 Retina
bot.

The relevant error log:

../../content/browser/renderer_host/input/web_input_event_builders_mac.mm:889:10:
error: use of undeclared identifier 'NSEventTypeSmartMagnify'; did you mean
'NSEventTypeMagnify'?
    case NSEventTypeSmartMagnify:
         ^~~~~~~~~~~~~~~~~~~~~~~
         NSEventTypeMagnify
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.6.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSEvent.h:48:5:
note: 'NSEventTypeMagnify' declared here
    NSEventTypeMagnify          = 30,
    ^
../../content/browser/renderer_host/input/web_input_event_builders_mac.mm:889:10:
error: duplicate case value 'NSEventTypeMagnify'
    case NSEventTypeSmartMagnify:
         ^
../../content/browser/renderer_host/input/web_input_event_builders_mac.mm:885:10:
note: previous case defined here
    case NSEventTypeMagnify:
         ^
2 errors generated.
ninja: build stopped: subcommand failed..

[dtapuska, 2015-09-16 14:09:03]

dtapuska@chromium.org changed reviewers:
+ thakis@chromium.org

[dtapuska, 2015-09-16 16:42:59]

The CQ bit was checked by dtapuska@chromium.org

[dtapuska, 2015-09-16 16:43:00]

The patchset sent to the CQ was uploaded after l-g-t-m from
mnaganov@chromium.org, asvitkine@chromium.org, wez@chromium.org,
sadrul@chromium.org, piman@chromium.org
Link to the patchset: https://codereview.chromium.org/1331013004/#ps160001
(title: "Remove forward declare as the bot got updated")

[commit-bot: I haz the power, 2015-09-16 16:43:27]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1331013004/160001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1331013004/160001

[dtapuska, 2015-09-16 16:44:55]

On 2015/09/16 01:18:10, Takayoshi Kochi wrote:
> A revert of this CL (patchset #7 id:120001) has been created in
> https://codereview.chromium.org/1345043003/ by mailto:kochi@chromium.org.
> 
> The reason for reverting is: This caused compile failure on MacOSX 10.9 Retina
> bot.
> 
> The relevant error log:
> 
>
../../content/browser/renderer_host/input/web_input_event_builders_mac.mm:889:10:
> error: use of undeclared identifier 'NSEventTypeSmartMagnify'; did you mean
> 'NSEventTypeMagnify'?
>     case NSEventTypeSmartMagnify:
>          ^~~~~~~~~~~~~~~~~~~~~~~
>          NSEventTypeMagnify
>
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.6.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSEvent.h:48:5:
> note: 'NSEventTypeMagnify' declared here
>     NSEventTypeMagnify          = 30,
>     ^
>
../../content/browser/renderer_host/input/web_input_event_builders_mac.mm:889:10:
> error: duplicate case value 'NSEventTypeMagnify'
>     case NSEventTypeSmartMagnify:
>          ^
>
../../content/browser/renderer_host/input/web_input_event_builders_mac.mm:885:10:
> note: previous case defined here
>     case NSEventTypeMagnify:
>          ^
> 2 errors generated.
> ninja: build stopped: subcommand failed..

The reason for the revert was because the build failed:
http://build.chromium.org/p/chromium.webkit/builders/WebKit%20Mac10.9%20%28re...

The problem is the min OS SDK really is 10.10; but the bot had 10.6 installed;
https://code.google.com/p/chromium/issues/detail?id=532504 fixed the bot so it
has a more recent SDK installed.

Re-landing change as the failing bot has been updated.

[commit-bot: I haz the power, 2015-09-16 17:53:40]

Committed patchset #9 (id:160001)

[commit-bot: I haz the power, 2015-09-16 17:54:26]

Patchset 9 (id:??) landed as
https://crrev.com/5405b8306550f01b86204d45fad3360593b39001
Cr-Commit-Position: refs/heads/master@{#349157}

[skobes, 2015-09-16 18:41:16]

A revert of this CL (patchset #9 id:160001) has been created in
https://codereview.chromium.org/1348843002/ by skobes@chromium.org.

The reason for reverting is:
http://build.chromium.org/p/chromium.webkit/builders/WebKit%20Mac10.9%20%28re...
../../content/browser/renderer_host/input/web_input_event_builders_mac.mm:889:10:
error: use of undeclared identifier 'NSEventTypeSmartMagnify'; did you mean
'NSEventTypeMagnify'?
    case NSEventTypeSmartMagnify:
         ^~~~~~~~~~~~~~~~~~~~~~~
         NSEventTypeMagnify.

[dtapuska, 2015-09-16 21:00:29]

On 2015/09/16 18:41:16, skobes wrote:
> A revert of this CL (patchset #9 id:160001) has been created in
> https://codereview.chromium.org/1348843002/ by mailto:skobes@chromium.org.
> 
> The reason for reverting is:
>
http://build.chromium.org/p/chromium.webkit/builders/WebKit%20Mac10.9%20%28re...
>
../../content/browser/renderer_host/input/web_input_event_builders_mac.mm:889:10:
> error: use of undeclared identifier 'NSEventTypeSmartMagnify'; did you mean
> 'NSEventTypeMagnify'?
>     case NSEventTypeSmartMagnify:
>          ^~~~~~~~~~~~~~~~~~~~~~~
>          NSEventTypeMagnify.

Bot has been updated to use 10.10 SDK in
https://codereview.chromium.org/1347213002/

Attempting to re-land this again; 3rd time is a charm right?

[dtapuska, 2015-09-16 21:00:44]

The CQ bit was checked by dtapuska@chromium.org

[commit-bot: I haz the power, 2015-09-16 21:01:12]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1331013004/160001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1331013004/160001

[commit-bot: I haz the power, 2015-09-16 21:09:32]

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

[commit-bot: I haz the power, 2015-09-16 21:09:33]

Try jobs failed on following builders:
  chromium_presubmit on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[dtapuska, 2015-09-17 12:11:41]

The CQ bit was checked by dtapuska@chromium.org

[commit-bot: I haz the power, 2015-09-17 12:11:55]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1331013004/160001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1331013004/160001

[commit-bot: I haz the power, 2015-09-17 12:17:13]

Committed patchset #9 (id:160001)

[commit-bot: I haz the power, 2015-09-17 12:17:58]

Patchset 9 (id:??) landed as
https://crrev.com/edc082cebb6e99f83859d9587ddf2971fe91b43c
Cr-Commit-Position: refs/heads/master@{#349404}

[commit-bot: I haz the power, 2015-09-23 12:49:26]

Patchset 9 (id:??) landed as
https://crrev.com/8db5ca887d4560ed15bf5e6e2dce69dc85868f25
Cr-Commit-Position: refs/heads/master@{#348989}

[commit-bot: I haz the power, 2015-09-23 12:57:41]

Patchset 9 (id:??) landed as
https://crrev.com/5405b8306550f01b86204d45fad3360593b39001
Cr-Commit-Position: refs/heads/master@{#349157}