Optionally have MessagePort pass data as base::Value, part 1.

Optionally have MessagePort pass data as base::Value, part 1.

Various efforts (android webview, navigator.connect) are experimenting
with using MessagePort as a way to communicate with native code. This is
a start at refactoring MessagePort code to make this possible.

This CL changes the IPCs for MessagePort messages to pass the data as
a MessagePortMessage struct, adding support to the renderer side
MessagePort code to support both base::Value and blink::WebSerializedScriptValue
messages. Additionally a (currently unset) flag is added that determines
how MessagePort sends messages back to the browser process.

This is part of a series of changes:
[1/5] Blink side changes in https://codereview.chromium.org/924983002/ that expose a needed v8 context
[2/5] This CL
[3/5] https://codereview.chromium.org/944443003/ which causes the send_messages_as_values flag to be propagated
[4/5] https://codereview.chromium.org/938403005/ which uses this for navigator.connect services and adds infrastructure for layout tests
[5/5] https://codereview.chromium.org/940423004/ adds layout tests to blink to test these new features

BUG=426458
Committed: https://crrev.com/09ac29ceebbed0fa9a4500ee6e78acb13ebf9eaa
Cr-Commit-Position: refs/heads/master@{#318492}

[Marijn Kruisselbrink, 2015-02-18 01:44:30]

Patchset #1 (id:1) has been deleted

[Marijn Kruisselbrink, 2015-02-18 01:44:35]

Patchset #1 (id:20001) has been deleted

[Marijn Kruisselbrink, 2015-02-18 01:44:40]

Patchset #1 (id:40001) has been deleted

[Marijn Kruisselbrink, 2015-02-18 01:48:21]

mek@chromium.org changed reviewers:
+ scheib@chromium.org

[adamk, 2015-02-18 20:30:07]

adamk@chromium.org changed reviewers:
+ adamk@chromium.org

[scheib, 2015-02-18 20:58:56]

lgtm

https://codereview.chromium.org/921013002/diff/60001/content/child/webmessage...
File content/child/webmessageportchannel_impl.cc (right):

https://codereview.chromium.org/921013002/diff/60001/content/child/webmessage...
content/child/webmessageportchannel_impl.cc:159: if
(message_queue_.front().message.message_as_value.Get(0,
Seems a bit implicit, would read cleanly with something like
MessagePortMessage::StoresAValue().

https://codereview.chromium.org/921013002/diff/60001/content/child/webmessage...
File content/child/webmessageportchannel_impl.h (right):

https://codereview.chromium.org/921013002/diff/60001/content/child/webmessage...
content/child/webmessageportchannel_impl.h:101: // Flag to indicate if messages
should be send to the browser process as
s/send/sent/

https://codereview.chromium.org/921013002/diff/60001/content/child/webmessage...
content/child/webmessageportchannel_impl.h:103: //
blink::WebSerializedScriptValue. Not currently ever set as there are some
Cite an issue#

[scheib, 2015-02-18 21:03:23]

https://codereview.chromium.org/921013002/diff/60001/content/public/common/me...
File content/public/common/message_port_message.h (right):

https://codereview.chromium.org/921013002/diff/60001/content/public/common/me...
content/public/common/message_port_message.h:21: explicit
MessagePortMessage(const base::Value* message);
Perhaps just take ownership of the message object instead of DeepCopy.

[adamk, 2015-02-18 21:34:46]

Thanks for the detailed explanation over in
https://codereview.chromium.org/924983002/. I've responded over here since it's
where the meat of the code is.

https://codereview.chromium.org/921013002/diff/60001/content/child/webmessage...
File content/child/webmessageportchannel_impl.cc (right):

https://codereview.chromium.org/921013002/diff/60001/content/child/webmessage...
content/child/webmessageportchannel_impl.cc:165:
converter->ToV8Value(message_as_value, client_->scriptContext());
This call can have side effects if there are setters on builtin prototypes (see
http://crbug.com/459731 for a related example). See 

https://code.google.com/p/chromium/codesearch#chromium/src/content/child/v8_v...

for how V8ValueConverter handles this. I'm worried that allowing author JS to
run at this time could have unforeseen consequences. Even if V8ValueConverter
were made safe, my reading of the SerializedScriptValue implementation in Blink
suggests that, for example, serializing an Array with holes can cause getters on
the prototype to be run:

https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit...

("Dense" is defined as "6 * propertyCount >= length", and the existing code
actually gets the property count wrong, from what I can tell).

In short, it looks to me like a variety of changes would need to be made in
V8ValueConverter and SerializedScriptValue before the conversions done here
could be done transparently, without the possibility of invoking author script.

So I'm inclined to push a bit harder on trying to come up with a more direct
SerializedScriptValue <-> base::Value translation that leaves out the JavaScript
middleman. You mentioned in the other patch that this would require significant
refactoring; do you have a sketch of that design, and how much work it might be?

[adamk, 2015-02-18 22:11:07]

From offline discussion, it seems the the major blocker on using something other
than v8::Value as an intermediate step is that Blink can't depend on
base::Value.

Given that this code is currently experimental and won't be turned on in
production in its current state, I'm cautiously OK with it (and the accompanying
Blink API change).

I've encouraged Marijn to avoid landing these two patches until he's able to
write tests exercising this code, though. In time meantime, it would be good to
understand what barriers keep us from using base::Value in Blink.

[Marijn Kruisselbrink, 2015-02-20 22:51:32]

New patchsets have been uploaded after l-g-t-m from scheib@chromium.org

[Marijn Kruisselbrink, 2015-02-20 23:15:41]

On 2015/02/18 22:11:07, adamk wrote:
> From offline discussion, it seems the the major blocker on using something
other
> than v8::Value as an intermediate step is that Blink can't depend on
> base::Value.
> 
> Given that this code is currently experimental and won't be turned on in
> production in its current state, I'm cautiously OK with it (and the
accompanying
> Blink API change).
> 
> I've encouraged Marijn to avoid landing these two patches until he's able to
> write tests exercising this code, though. In time meantime, it would be good
to
> understand what barriers keep us from using base::Value in Blink.
I completely agree that landing this without tests using it is a bad idea, so
I've
uploaded 3 more CLs:
- one CL that causes this send_messages_as_values flag to propagate when ports
  are transferred,
- one CL that sets this flag when a navigator.connect service asks for it, and
adds
  testing infrastructure,
- and one CL that adds a couple of layout tests to test all this

[Marijn Kruisselbrink, 2015-02-26 18:48:25]

mek@chromium.org changed reviewers:
+ avi@chromium.org

[Marijn Kruisselbrink, 2015-02-26 18:48:26]

+avi for content/ OWNERS

[Avi (use Gerrit), 2015-02-26 19:08:53]

lgtm

stamp

https://codereview.chromium.org/921013002/diff/120001/content/child/webmessag...
File content/child/webmessageportchannel_impl.h (right):

https://codereview.chromium.org/921013002/diff/120001/content/child/webmessag...
content/child/webmessageportchannel_impl.h:101: // Flag to indicate if messages
should be send to the browser process as
... should be sent ...

[scheib, 2015-02-26 21:33:47]

mek@, looks like you overlooked addressing my comments from #7.

[Marijn Kruisselbrink, 2015-02-26 23:12:54]

On 2015/02/26 21:33:47, scheib wrote:
> mek@, looks like you overlooked addressing my comments from #7.
Oops, I'm really sorry about that, not sure how I missed that.

https://codereview.chromium.org/921013002/diff/60001/content/child/webmessage...
File content/child/webmessageportchannel_impl.cc (right):

https://codereview.chromium.org/921013002/diff/60001/content/child/webmessage...
content/child/webmessageportchannel_impl.cc:159: if
(message_queue_.front().message.message_as_value.Get(0,
On 2015/02/18 20:58:55, scheib wrote:
> Seems a bit implicit, would read cleanly with something like
> MessagePortMessage::StoresAValue().

Done.

https://codereview.chromium.org/921013002/diff/60001/content/child/webmessage...
File content/child/webmessageportchannel_impl.h (right):

https://codereview.chromium.org/921013002/diff/60001/content/child/webmessage...
content/child/webmessageportchannel_impl.h:101: // Flag to indicate if messages
should be send to the browser process as
On 2015/02/18 20:58:55, scheib wrote:
> s/send/sent/

Done.

https://codereview.chromium.org/921013002/diff/60001/content/child/webmessage...
content/child/webmessageportchannel_impl.h:103: //
blink::WebSerializedScriptValue. Not currently ever set as there are some
On 2015/02/18 20:58:55, scheib wrote:
> Cite an issue#

Actually I just removed this part of the comment, since the next patch in this
series would make this untrue anyway.

https://codereview.chromium.org/921013002/diff/60001/content/public/common/me...
File content/public/common/message_port_message.h (right):

https://codereview.chromium.org/921013002/diff/60001/content/public/common/me...
content/public/common/message_port_message.h:21: explicit
MessagePortMessage(const base::Value* message);
On 2015/02/18 21:03:23, scheib wrote:
> Perhaps just take ownership of the message object instead of DeepCopy. 

Done.

https://codereview.chromium.org/921013002/diff/120001/content/child/webmessag...
File content/child/webmessageportchannel_impl.h (right):

https://codereview.chromium.org/921013002/diff/120001/content/child/webmessag...
content/child/webmessageportchannel_impl.h:101: // Flag to indicate if messages
should be send to the browser process as
On 2015/02/26 19:08:53, Avi wrote:
> ... should be sent ...

Done.

[Marijn Kruisselbrink, 2015-02-27 00:34:25]

Patchset #7 (id:180001) has been deleted

[Marijn Kruisselbrink, 2015-02-27 00:58:36]

Patchset #7 (id:200001) has been deleted

[Marijn Kruisselbrink, 2015-02-27 01:05:42]

mek@chromium.org changed reviewers:
+ sgurun@chromium.org, tsepez@chromium.org

[Marijn Kruisselbrink, 2015-02-27 01:05:43]

+sgurun for android_webview OWNERS
+tsepez for IPC OWNERS

[sgurun-gerrit only, 2015-02-27 03:17:19]

On 2015/02/27 01:05:43, Marijn Kruisselbrink wrote:
> +sgurun for android_webview OWNERS
> +tsepez for IPC OWNERS

[sgurun-gerrit only, 2015-02-27 03:17:37]

https://codereview.chromium.org/921013002/diff/220001/android_webview/browser...
File android_webview/browser/aw_message_port_message_filter.cc (right):

https://codereview.chromium.org/921013002/diff/220001/android_webview/browser...
android_webview/browser/aw_message_port_message_filter.cc:51: // to the renderer
directly.
I don't know what you ended up designing for converting messages for
navigator.connect, but I am not very sure if it will work in webview case. let's
first talk about it before doing anything.

also, I don't think we want to introduce v8 usages in browser side for
multiprocess case.

https://codereview.chromium.org/921013002/diff/220001/content/public/common/m...
File content/public/common/message_port_types.h (right):

https://codereview.chromium.org/921013002/diff/220001/content/public/common/m...
content/public/common/message_port_types.h:37: base::ListValue message_as_value;
can't base::listvalue carry a string? why introduce the MessagePortMessage? is
it just temporary.

[Marijn Kruisselbrink, 2015-02-27 05:00:58]

https://codereview.chromium.org/921013002/diff/220001/android_webview/browser...
File android_webview/browser/aw_message_port_message_filter.cc (right):

https://codereview.chromium.org/921013002/diff/220001/android_webview/browser...
android_webview/browser/aw_message_port_message_filter.cc:51: // to the renderer
directly.
On 2015/02/27 03:17:36, sgurun wrote:
> I don't know what you ended up designing for converting messages for
> navigator.connect, but I am not very sure if it will work in webview case.
let's
> first talk about it before doing anything.
Well, messages send from the browser to a MessagePort (which this code and this
TODO is about) are easy in any solution. There is no need for an extra
roundtrip, the browser can just send the base::Value to the MessagePort, and
with this CL the MessagePort will then do the conversion.

For the reverse, sending messages from a MessagePort to code in the browser
process, what I've implemented here won't work for the android webview case,
because of the extra requirements you had for being able to freely transfer
around both ends of these channels.

I'll happily talk more, but I'm not sure why figuring out a complete solution
that works for both android webview and navigator.connect should block
implementing a temporary solution for navigator.connect (it certainly doesn't
seem to have stopped implementing the webview specific "hacks").

> 
> also, I don't think we want to introduce v8 usages in browser side for
> multiprocess case. 

Of course. I have no plans whatsoever to add any kind of v8 usage in the browser
process.

https://codereview.chromium.org/921013002/diff/220001/content/public/common/m...
File content/public/common/message_port_types.h (right):

https://codereview.chromium.org/921013002/diff/220001/content/public/common/m...
content/public/common/message_port_types.h:37: base::ListValue message_as_value;
On 2015/02/27 03:17:37, sgurun wrote:
> can't base::listvalue carry a string? why introduce the MessagePortMessage? is
> it just temporary.

Yes, base::ListValue could carry a string. It would require converting the UTF16
string to UTF8 (and vice versa), which since these are not even really strings
might have weird effects. I'm also not sure how that would be better though.
Yes, instead of base::Value + base::string16 MessagePortMessage could be a
base::Value + some enum to define what type is stored in the value (or some
other hack to store that information), but it seems much clearer to just keep
this separated. One field for messages that are encoded as
SerializedScriptValue, and one field for messages that are send as base::Value.

[sgurun-gerrit only, 2015-02-27 18:06:50]

https://codereview.chromium.org/921013002/diff/220001/android_webview/browser...
File android_webview/browser/aw_message_port_message_filter.cc (right):

https://codereview.chromium.org/921013002/diff/220001/android_webview/browser...
android_webview/browser/aw_message_port_message_filter.cc:51: // to the renderer
directly.
On 2015/02/27 05:00:57, Marijn Kruisselbrink wrote:
> On 2015/02/27 03:17:36, sgurun wrote:
> > I don't know what you ended up designing for converting messages for
> > navigator.connect, but I am not very sure if it will work in webview case.
> let's
> > first talk about it before doing anything.
> Well, messages send from the browser to a MessagePort (which this code and
this
> TODO is about) are easy in any solution. There is no need for an extra
> roundtrip, the browser can just send the base::Value to the MessagePort, and
> with this CL the MessagePort will then do the conversion.
> 
> For the reverse, sending messages from a MessagePort to code in the browser
> process, what I've implemented here won't work for the android webview case,
> because of the extra requirements you had for being able to freely transfer
> around both ends of these channels.

ok I just wanted to understand what overall solution you came up with after the
design document you provided, since I did not hear again.  

> 
> I'll happily talk more, but I'm not sure why figuring out a complete solution
> that works for both android webview and navigator.connect should block
> implementing a temporary solution for navigator.connect (it certainly doesn't
> seem to have stopped implementing the webview specific "hacks").
I think you misunderstood. Where did I imply we should block it? I wanted to
make sure any new work you are doing is compatible with anything we are
planning.

> 
> > 
> > also, I don't think we want to introduce v8 usages in browser side for
> > multiprocess case. 
> 
> Of course. I have no plans whatsoever to add any kind of v8 usage in the
browser
> process.

https://codereview.chromium.org/921013002/diff/220001/content/public/common/m...
File content/public/common/message_port_types.h (right):

https://codereview.chromium.org/921013002/diff/220001/content/public/common/m...
content/public/common/message_port_types.h:37: base::ListValue message_as_value;
On 2015/02/27 05:00:57, Marijn Kruisselbrink wrote:
> On 2015/02/27 03:17:37, sgurun wrote:
> > can't base::listvalue carry a string? why introduce the MessagePortMessage?
is
> > it just temporary.
> 
> Yes, base::ListValue could carry a string. It would require converting the
UTF16
> string to UTF8 (and vice versa), which since these are not even really strings
> might have weird effects. I'm also not sure how that would be better though.
> Yes, instead of base::Value + base::string16 MessagePortMessage could be a
> base::Value + some enum to define what type is stored in the value (or some
> other hack to store that information), but it seems much clearer to just keep
> this separated. One field for messages that are encoded as
> SerializedScriptValue, and one field for messages that are send as
base::Value.

are you sure this is right? base::value seems to allow setting and getting a
string16.

[Tom Sepez, 2015-02-27 18:16:06]

Messages LGTM.

https://codereview.chromium.org/921013002/diff/220001/content/common/message_...
File content/common/message_port_messages.h (right):

https://codereview.chromium.org/921013002/diff/220001/content/common/message_...
content/common/message_port_messages.h:25: // Singly-included section, not
converted.
nit: As long as you're mucking with this, my comment at this line is getting a
little out of date.  Changing this to
// Singly-included section for typedefs.
would be appreciated by me.  Thanks.

[Marijn Kruisselbrink, 2015-02-27 18:17:51]

https://codereview.chromium.org/921013002/diff/220001/android_webview/browser...
File android_webview/browser/aw_message_port_message_filter.cc (right):

https://codereview.chromium.org/921013002/diff/220001/android_webview/browser...
android_webview/browser/aw_message_port_message_filter.cc:51: // to the renderer
directly.
On 2015/02/27 18:06:50, sgurun wrote:
> On 2015/02/27 05:00:57, Marijn Kruisselbrink wrote:
> > On 2015/02/27 03:17:36, sgurun wrote:
> > > I don't know what you ended up designing for converting messages for
> > > navigator.connect, but I am not very sure if it will work in webview case.
> > let's
> > > first talk about it before doing anything.
> > Well, messages send from the browser to a MessagePort (which this code and
> this
> > TODO is about) are easy in any solution. There is no need for an extra
> > roundtrip, the browser can just send the base::Value to the MessagePort, and
> > with this CL the MessagePort will then do the conversion.
> > 
> > For the reverse, sending messages from a MessagePort to code in the browser
> > process, what I've implemented here won't work for the android webview case,
> > because of the extra requirements you had for being able to freely transfer
> > around both ends of these channels.
> 
> ok I just wanted to understand what overall solution you came up with after
the
> design document you provided, since I did not hear again.  
> 
> > 
> > I'll happily talk more, but I'm not sure why figuring out a complete
solution
> > that works for both android webview and navigator.connect should block
> > implementing a temporary solution for navigator.connect (it certainly
doesn't
> > seem to have stopped implementing the webview specific "hacks").
> I think you misunderstood. Where did I imply we should block it? I wanted to
> make sure any new work you are doing is compatible with anything we are
> planning.
Yes, it would be nice to be kept in the loop on anything you are planning. I
guess I misunderstood "let's first talk [...] before doing anything" as meaning
you wouldn't approve this CL (and future ones needed for navigator.connect)
until we've fully worked out a solution that works for both.

https://codereview.chromium.org/921013002/diff/220001/content/public/common/m...
File content/public/common/message_port_types.h (right):

https://codereview.chromium.org/921013002/diff/220001/content/public/common/m...
content/public/common/message_port_types.h:37: base::ListValue message_as_value;
On 2015/02/27 18:06:50, sgurun wrote:
> On 2015/02/27 05:00:57, Marijn Kruisselbrink wrote:
> > On 2015/02/27 03:17:37, sgurun wrote:
> > > can't base::listvalue carry a string? why introduce the
MessagePortMessage?
> is
> > > it just temporary.
> > 
> > Yes, base::ListValue could carry a string. It would require converting the
> UTF16
> > string to UTF8 (and vice versa), which since these are not even really
strings
> > might have weird effects. I'm also not sure how that would be better though.
> > Yes, instead of base::Value + base::string16 MessagePortMessage could be a
> > base::Value + some enum to define what type is stored in the value (or some
> > other hack to store that information), but it seems much clearer to just
keep
> > this separated. One field for messages that are encoded as
> > SerializedScriptValue, and one field for messages that are send as
> base::Value.
> 
> are you sure this is right? base::value seems to allow setting and getting a
> string16.

If you look at the base::string16 methods of base::StringValue, you see they use
UTF16ToUTF8 when setting and UTF8ToUTF16 when getting.

[Marijn Kruisselbrink, 2015-02-27 18:20:16]

https://codereview.chromium.org/921013002/diff/220001/content/common/message_...
File content/common/message_port_messages.h (right):

https://codereview.chromium.org/921013002/diff/220001/content/common/message_...
content/common/message_port_messages.h:25: // Singly-included section, not
converted.
On 2015/02/27 18:16:05, Tom Sepez wrote:
> nit: As long as you're mucking with this, my comment at this line is getting a
> little out of date.  Changing this to
> // Singly-included section for typedefs.
> would be appreciated by me.  Thanks.

Done.

[sgurun-gerrit only, 2015-02-27 18:33:13]

On 2015/02/27 18:20:16, Marijn Kruisselbrink wrote:
>
https://codereview.chromium.org/921013002/diff/220001/content/common/message_...
> File content/common/message_port_messages.h (right):
> 
>
https://codereview.chromium.org/921013002/diff/220001/content/common/message_...
> content/common/message_port_messages.h:25: // Singly-included section, not
> converted.
> On 2015/02/27 18:16:05, Tom Sepez wrote:
> > nit: As long as you're mucking with this, my comment at this line is getting
a
> > little out of date.  Changing this to
> > // Singly-included section for typedefs.
> > would be appreciated by me.  Thanks.
> 
> Done.

lgtm

[sgurun-gerrit only, 2015-02-27 18:33:26]

https://codereview.chromium.org/921013002/diff/220001/android_webview/browser...
File android_webview/browser/aw_message_port_message_filter.cc (right):

https://codereview.chromium.org/921013002/diff/220001/android_webview/browser...
android_webview/browser/aw_message_port_message_filter.cc:51: // to the renderer
directly.
On 2015/02/27 18:17:51, Marijn Kruisselbrink wrote:
> On 2015/02/27 18:06:50, sgurun wrote:
> > On 2015/02/27 05:00:57, Marijn Kruisselbrink wrote:
> > > On 2015/02/27 03:17:36, sgurun wrote:
> > > > I don't know what you ended up designing for converting messages for
> > > > navigator.connect, but I am not very sure if it will work in webview
case.
> > > let's
> > > > first talk about it before doing anything.
> > > Well, messages send from the browser to a MessagePort (which this code and
> > this
> > > TODO is about) are easy in any solution. There is no need for an extra
> > > roundtrip, the browser can just send the base::Value to the MessagePort,
and
> > > with this CL the MessagePort will then do the conversion.
> > > 
> > > For the reverse, sending messages from a MessagePort to code in the
browser
> > > process, what I've implemented here won't work for the android webview
case,
> > > because of the extra requirements you had for being able to freely
transfer
> > > around both ends of these channels.
> > 
> > ok I just wanted to understand what overall solution you came up with after
> the
> > design document you provided, since I did not hear again.  
> > 
> > > 
> > > I'll happily talk more, but I'm not sure why figuring out a complete
> solution
> > > that works for both android webview and navigator.connect should block
> > > implementing a temporary solution for navigator.connect (it certainly
> doesn't
> > > seem to have stopped implementing the webview specific "hacks").
> > I think you misunderstood. Where did I imply we should block it? I wanted to
> > make sure any new work you are doing is compatible with anything we are
> > planning.
> Yes, it would be nice to be kept in the loop on anything you are planning. I
> guess I misunderstood "let's first talk [...] before doing anything" as
meaning
> you wouldn't approve this CL (and future ones needed for navigator.connect)
> until we've fully worked out a solution that works for both.

my comment is wrt to the webview that you mentioned in TODO.

https://codereview.chromium.org/921013002/diff/220001/content/public/common/m...
File content/public/common/message_port_types.h (right):

https://codereview.chromium.org/921013002/diff/220001/content/public/common/m...
content/public/common/message_port_types.h:37: base::ListValue message_as_value;
On 2015/02/27 18:17:51, Marijn Kruisselbrink wrote:
> On 2015/02/27 18:06:50, sgurun wrote:
> > On 2015/02/27 05:00:57, Marijn Kruisselbrink wrote:
> > > On 2015/02/27 03:17:37, sgurun wrote:
> > > > can't base::listvalue carry a string? why introduce the
> MessagePortMessage?
> > is
> > > > it just temporary.
> > > 
> > > Yes, base::ListValue could carry a string. It would require converting the
> > UTF16
> > > string to UTF8 (and vice versa), which since these are not even really
> strings
> > > might have weird effects. I'm also not sure how that would be better
though.
> > > Yes, instead of base::Value + base::string16 MessagePortMessage could be a
> > > base::Value + some enum to define what type is stored in the value (or
some
> > > other hack to store that information), but it seems much clearer to just
> keep
> > > this separated. One field for messages that are encoded as
> > > SerializedScriptValue, and one field for messages that are send as
> > base::Value.
> > 
> > are you sure this is right? base::value seems to allow setting and getting a
> > string16.
> 
> If you look at the base::string16 methods of base::StringValue, you see they
use
> UTF16ToUTF8 when setting and UTF8ToUTF16 when getting.

huh, that is interesting. I guess something to address in future.

[Marijn Kruisselbrink, 2015-02-27 18:34:39]

The CQ bit was checked by mek@chromium.org

[Marijn Kruisselbrink, 2015-02-27 18:34:39]

The patchset sent to the CQ was uploaded after l-g-t-m from scheib@chromium.org,
avi@chromium.org, tsepez@chromium.org
Link to the patchset: https://codereview.chromium.org/921013002/#ps240001
(title: "Update singly-included comment")

[commit-bot: I haz the power, 2015-02-27 18:35:41]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/921013002/240001

[commit-bot: I haz the power, 2015-02-27 19:13:02]

Committed patchset #8 (id:240001)

[commit-bot: I haz the power, 2015-02-27 19:14:13]

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