Reland: Plugin Placeholders: Refactor for platforms that don't support plugins

Reland: Plugin Placeholders: Refactor for platforms that don't support plugins

This patch removes a lot of plugin placeholder code from builds that don't support plugins (enable_plugins==0).

This is a reland of https://codereview.chromium.org/1126073003/.

See patchsets for fixes of the crashes.

BUG=493889
TBR=

Committed: https://crrev.com/425d6965196e7448a2ba9180a3fd2f5b08f5b329
Cr-Commit-Position: refs/heads/master@{#334054}

[tommycli, 2015-05-29 20:26:33]

The CQ bit was checked by tommycli@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2015-05-29 20:28:02]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1161923004/20001

[commit-bot: I haz the power, 2015-05-29 22:06:01]

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

[commit-bot: I haz the power, 2015-05-29 22:06:02]

Dry run: Try jobs failed on following builders:
  linux_chromium_rel_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[tommycli, 2015-06-01 17:59:39]

Patchset #2 (id:20001) has been deleted

[tommycli, 2015-06-01 21:42:31]

Patchset #3 (id:60001) has been deleted

[tommycli, 2015-06-01 21:42:41]

Patchset #2 (id:40001) has been deleted

[tommycli, 2015-06-01 21:44:51]

Patchset #2 (id:80001) has been deleted

[tommycli, 2015-06-01 22:37:49]

The CQ bit was checked by tommycli@chromium.org to run a CQ dry run

[tommycli, 2015-06-01 22:58:11]

Patchset #3 (id:120001) has been deleted

[tommycli, 2015-06-01 22:58:17]

The CQ bit was checked by tommycli@chromium.org to run a CQ dry run

[tommycli, 2015-06-01 23:00:09]

Patchset #3 (id:130001) has been deleted

[tommycli, 2015-06-01 23:00:30]

The CQ bit was checked by tommycli@chromium.org to run a CQ dry run

[tommycli, 2015-06-01 23:02:24]

tommycli@chromium.org changed reviewers:
+ bauerb@chromium.org, jochen@chromium.org

[tommycli, 2015-06-01 23:11:57]

bauerb, jochen:

This patch is ready for a re-review.

Patchset #1 is the already-approved version that was reverted.
Patchset #2 fixes the cause of the crashes.
Patchset #3 does a merge with origin/master and eliminates a class
(TestPluginPlaceholder) that's no longer necessary.

[commit-bot: I haz the power, 2015-06-01 23:34:20]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1161923004/150001

[commit-bot: I haz the power, 2015-06-02 01:04:38]

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

[commit-bot: I haz the power, 2015-06-02 01:04:39]

Dry run: Try jobs failed on following builders:
  linux_chromium_rel_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[Bernhard Bauer, 2015-06-02 04:02:13]

LGTM!

[jochen (gone - plz use gerrit), 2015-06-02 16:17:13]

lgtm

[tommycli, 2015-06-02 18:51:54]

The CQ bit was checked by tommycli@chromium.org to run a CQ dry run

[tommycli, 2015-06-02 18:51:55]

The patchset sent to the CQ was uploaded after l-g-t-m from bauerb@chromium.org,
jochen@chromium.org
Link to the patchset: https://codereview.chromium.org/1161923004/#ps170001
(title: "One more fix necessary to support T subclasses.")

[commit-bot: I haz the power, 2015-06-02 18:53:52]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1161923004/170001

[commit-bot: I haz the power, 2015-06-02 19:24:31]

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

[commit-bot: I haz the power, 2015-06-02 19:24:33]

Dry run: Try jobs failed on following builders:
  android_chromium_gn_compile_dbg on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/android_chromiu...)
  android_chromium_gn_compile_rel on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/android_chromiu...)

[tommycli, 2015-06-02 21:02:02]

The CQ bit was checked by tommycli@chromium.org to run a CQ dry run

[tommycli, 2015-06-02 21:02:02]

The patchset sent to the CQ was uploaded after l-g-t-m from bauerb@chromium.org,
jochen@chromium.org
Link to the patchset: https://codereview.chromium.org/1161923004/#ps190001
(title: "Update unit tests.")

[commit-bot: I haz the power, 2015-06-02 21:02:35]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1161923004/190001

[commit-bot: I haz the power, 2015-06-02 21:13:29]

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

[commit-bot: I haz the power, 2015-06-02 21:13:30]

Dry run: Try jobs failed on following builders:
  android_chromium_gn_compile_rel on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/android_chromiu...)
  linux_chromium_compile_dbg_32_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  ios_dbg_simulator_ninja on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios_dbg_simulator...)
  ios_rel_device_ninja on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios_rel_device_ni...)

[tommycli, 2015-06-02 21:23:43]

The CQ bit was checked by tommycli@chromium.org to run a CQ dry run

[tommycli, 2015-06-02 21:23:43]

The patchset sent to the CQ was uploaded after l-g-t-m from bauerb@chromium.org,
jochen@chromium.org
Link to the patchset: https://codereview.chromium.org/1161923004/#ps210001
(title: "Merge to solve patch conflicts again...")

[commit-bot: I haz the power, 2015-06-02 21:24:13]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1161923004/210001

[commit-bot: I haz the power, 2015-06-02 21:58:12]

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

[commit-bot: I haz the power, 2015-06-02 21:58:14]

Dry run: Try jobs failed on following builders:
  android_compile_dbg on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/android_compile...)

[tommycli, 2015-06-02 22:01:24]

jochen: PTAL. I apologize, but this probably needs another look.

There were some other subtleties of subclassing Wrappable<T> that wasn't working
right.

I made some further changes to the gin/* stuff.

https://codereview.chromium.org/1161923004/diff/210001/gin/wrappable.h
File gin/wrappable.h (right):

https://codereview.chromium.org/1161923004/diff/210001/gin/wrappable.h#newcod...
gin/wrappable.h:103: static bool FromV8(v8::Isolate* isolate,
v8::Local<v8::Value> val, T** out) {
These changes are inspired by reverting some changes of a year ago:
https://codereview.chromium.org/105743007/diff/100001/gin/wrappable.h

https://codereview.chromium.org/1161923004/diff/210001/gin/wrappable.h#newcod...
gin/wrappable.h:123: // GetWrapperInfo(). This is unfortunate, but needed to
support subclasses.
I tried various methods for hours, but my conclusion is: We cannot
simultaneously support subclassing T and also be able to detect if the stored
pointer is really an object that derives from T, since GetWrapperInfo() can be
overridden.

This is lame, but I think most calls into this function are created via the
ObjectTemplateBuilder, which won't make this mistake...

https://codereview.chromium.org/1161923004/diff/210001/gin/wrappable_unittest.cc
File gin/wrappable_unittest.cc (right):

https://codereview.chromium.org/1161923004/diff/210001/gin/wrappable_unittest...
gin/wrappable_unittest.cc:191: gin::Handle<MyObject> base_class_instance =
MyObject::Create(isolate);
This test tickles the problem that caused those mystery crashes that perplexed
us all last week. (Subclass and base class using same WrapperInfo* and caching
incorrect object templates)

[tommycli, 2015-06-02 22:02:23]

thestig: FYI, will probably reland this soon. I haven't made any substantive
chrome/ changes.

[tommycli, 2015-06-03 23:23:17]

On 2015/06/02 22:02:23, tommycli wrote:
> thestig: FYI, will probably reland this soon. I haven't made any substantive
> chrome/ changes.

jochen: friendly ping if available

[tommycli, 2015-06-04 23:30:52]

On 2015/06/03 23:23:17, tommycli wrote:
> On 2015/06/02 22:02:23, tommycli wrote:
> > thestig: FYI, will probably reland this soon. I haven't made any substantive
> > chrome/ changes.
> 
> jochen: friendly ping if available

jochen: ping

[jochen (gone - plz use gerrit), 2015-06-08 09:28:29]

hum, so the thing is, we can only store one this pointer per object

this "this" pointer has to be exactly the C++ type that is expected by all
callbacks we define.

that means, the callbacks have to be defined either all on the most derived
class or all on the base class.

so I don't understand why we'd need a virtual kWrapperType?

[jochen (gone - plz use gerrit), 2015-06-08 09:38:37]

jochen@chromium.org changed reviewers:
+ chrishtr@chromium.org

[jochen (gone - plz use gerrit), 2015-06-08 09:38:38]

+chrishtr who's hacking on the test plugin placeholder

[tommycli, 2015-06-08 17:36:51]

On 2015/06/08 09:28:29, jochen wrote:
> hum, so the thing is, we can only store one this pointer per object
> 
> this "this" pointer has to be exactly the C++ type that is expected by all
> callbacks we define.
> 
> that means, the callbacks have to be defined either all on the most derived
> class or all on the base class.
> 
> so I don't understand why we'd need a virtual kWrapperType?

Hi jochen,

The 'this' pointer seems to be adjusted correctly for base class member
functions, so it's okay that some callbacks are defined on base classes.

However, the object templates are cached using the pointer address of
gin::WrapperInfo* as the key in the dictionary. If we don't have a virtual
GetWrapperInfo(), then the base class and subclasses share the same cached
object template.

If there is no virtual GetWrapperInfo(), and if DerivedClass defines some extra
methods, and is constructed first, then we will add the following entry into the
object template cache:

&BaseClass::kWrapperInfo -> (Derived class object template)

Then afterwards, if we construct an instance of BaseClass, we will use the
cached Derived class object template, and cause crashes.

The virtual GetWrapperInfo() allows for separate cached object templates, i.e.:

&DerivedClass::kWrapperInfo -> (Derived class object template)
&BaseClass::kWrapperInfo -> (Base class object template)

Thanks!

[jochen (gone - plz use gerrit), 2015-06-09 07:53:41]

On 2015/06/08 at 17:36:51, tommycli wrote:
> On 2015/06/08 09:28:29, jochen wrote:
> > hum, so the thing is, we can only store one this pointer per object
> > 
> > this "this" pointer has to be exactly the C++ type that is expected by all
> > callbacks we define.
> > 
> > that means, the callbacks have to be defined either all on the most derived
> > class or all on the base class.
> > 
> > so I don't understand why we'd need a virtual kWrapperType?
> 
> Hi jochen,
> 
> The 'this' pointer seems to be adjusted correctly for base class member
functions, so it's okay that some callbacks are defined on base classes.

There is not pointer adjustment, however, in the code, is there?

> 
> However, the object templates are cached using the pointer address of
gin::WrapperInfo* as the key in the dictionary. If we don't have a virtual
GetWrapperInfo(), then the base class and subclasses share the same cached
object template.

the wrapper type info should be defined on the most derived classs, and the most
derived class should implement all methods. It can forward to the base class in
C++

> 
> If there is no virtual GetWrapperInfo(), and if DerivedClass defines some
extra methods, and is constructed first, then we will add the following entry
into the object template cache:
> 
> &BaseClass::kWrapperInfo -> (Derived class object template)
> 
> Then afterwards, if we construct an instance of BaseClass, we will use the
cached Derived class object template, and cause crashes.
> 
> The virtual GetWrapperInfo() allows for separate cached object templates,
i.e.:
> 
> &DerivedClass::kWrapperInfo -> (Derived class object template)
> &BaseClass::kWrapperInfo -> (Base class object template)
> 
> Thanks!

[tommycli, 2015-06-09 18:40:42]

On 2015/06/09 07:53:41, jochen wrote:
> On 2015/06/08 at 17:36:51, tommycli wrote:
> > On 2015/06/08 09:28:29, jochen wrote:
> > > hum, so the thing is, we can only store one this pointer per object
> > > 
> > > this "this" pointer has to be exactly the C++ type that is expected by all
> > > callbacks we define.
> > > 
> > > that means, the callbacks have to be defined either all on the most
derived
> > > class or all on the base class.
> > > 
> > > so I don't understand why we'd need a virtual kWrapperType?
> > 
> > Hi jochen,
> > 
> > The 'this' pointer seems to be adjusted correctly for base class member
> functions, so it's okay that some callbacks are defined on base classes.
> 
> There is not pointer adjustment, however, in the code, is there?

I think it "just works".

I updated the wrappable_unittest in the latest patch to make sure the pointers
were adjusted correctly. I also took some DLOGs from the gin_unittest and the
pointer seem adjusted correctly when the object template is constructed:

[19520:19520:0609/113528:1898036670690:INFO:wrappable_unittest.cc(78)]
MyObjectSubclass::GetObjectTemplateBuilder this=0x20dc720
[19520:19520:0609/113528:1898036670721:INFO:wrappable_unittest.cc(34)]
MyObject::GetObjectTemplateBuilder this=0x20dc730
[19520:19520:0609/113528:1898036670889:INFO:wrappable_unittest.cc(27)]
MyObject::value() this=0x20dc730
[19520:19520:0609/113528:1898036670947:INFO:wrappable_unittest.cc(69)]
MyObjectSubclass::SayHello() this=0x20dc720

> 
> > 
> > However, the object templates are cached using the pointer address of
> gin::WrapperInfo* as the key in the dictionary. If we don't have a virtual
> GetWrapperInfo(), then the base class and subclasses share the same cached
> object template.
> 
> the wrapper type info should be defined on the most derived classs, and the
most
> derived class should implement all methods. It can forward to the base class
in
> C++
> 

Ah, yes, that would work.

However, subclass support for gin::Wrappable is still broken. We should either
fix subclass support, or explicitly disallow Wrappable subclasses.

There is an example unit test in WrappableTest.WrappableSubclass. However, this
test will fail if you create a MyObject instance right before the
MyObjectSubclass instance in that test.

> > 
> > If there is no virtual GetWrapperInfo(), and if DerivedClass defines some
> extra methods, and is constructed first, then we will add the following entry
> into the object template cache:
> > 
> > &BaseClass::kWrapperInfo -> (Derived class object template)
> > 
> > Then afterwards, if we construct an instance of BaseClass, we will use the
> cached Derived class object template, and cause crashes.
> > 
> > The virtual GetWrapperInfo() allows for separate cached object templates,
> i.e.:
> > 
> > &DerivedClass::kWrapperInfo -> (Derived class object template)
> > &BaseClass::kWrapperInfo -> (Base class object template)
> > 
> > Thanks!

[tommycli, 2015-06-09 18:40:55]

The CQ bit was checked by tommycli@chromium.org to run a CQ dry run

[tommycli, 2015-06-09 18:40:55]

The patchset sent to the CQ was uploaded after l-g-t-m from bauerb@chromium.org,
jochen@chromium.org
Link to the patchset: https://codereview.chromium.org/1161923004/#ps230001
(title: "Add base class method call to unittest-")

[commit-bot: I haz the power, 2015-06-09 18:41:17]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1161923004/230001

[commit-bot: I haz the power, 2015-06-09 18:46:39]

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

[commit-bot: I haz the power, 2015-06-09 18:46:41]

Dry run: Try jobs failed on following builders:
  linux_chromium_compile_dbg_32_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  ios_dbg_simulator_ninja on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios_dbg_simulator...)
  ios_rel_device_ninja on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios_rel_device_ni...)
  mac_chromium_compile_dbg_ng on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)
  mac_chromium_rel_ng on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[tommycli, 2015-06-09 19:11:17]

The CQ bit was checked by tommycli@chromium.org to run a CQ dry run

[tommycli, 2015-06-09 19:11:18]

The patchset sent to the CQ was uploaded after l-g-t-m from bauerb@chromium.org,
jochen@chromium.org
Link to the patchset: https://codereview.chromium.org/1161923004/#ps250001
(title: "merge origin/master changes")

[commit-bot: I haz the power, 2015-06-09 19:12:18]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1161923004/250001

[commit-bot: I haz the power, 2015-06-09 19:42:53]

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

[commit-bot: I haz the power, 2015-06-09 19:42:56]

Dry run: Try jobs failed on following builders:
  linux_android_rel_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_android_r...)

[tommycli, 2015-06-09 23:40:17]

The CQ bit was checked by tommycli@chromium.org to run a CQ dry run

[tommycli, 2015-06-09 23:40:18]

The patchset sent to the CQ was uploaded after l-g-t-m from bauerb@chromium.org,
jochen@chromium.org
Link to the patchset: https://codereview.chromium.org/1161923004/#ps270001
(title: " ")

[commit-bot: I haz the power, 2015-06-09 23:40:41]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1161923004/270001

[tommycli, 2015-06-10 00:13:03]

Jochen: I made a new version based on your suggestions (Patchset 9) that removes
the Wrappable subclassing and forbids it in gin.

I think I like it better. Let me know what you think.

[commit-bot: I haz the power, 2015-06-10 01:44:04]

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

[commit-bot: I haz the power, 2015-06-10 01:44:05]

Dry run: This issue passed the CQ dry run.

[jochen (gone - plz use gerrit), 2015-06-11 12:46:35]

lgtm

[tommycli, 2015-06-11 17:31:22]

Patchset #10 (id:290001) has been deleted

[tommycli, 2015-06-11 17:33:25]

chrishtr: Any objections to the removal of the TestPluginPlaceholder in favor of
the plain PluginPlaceholder?

bauerb: The plugin placeholder code had to be further changed to avoid the
crashes without making extensive gin::Wrappable changes. Feel free to object /
re-review if you desire.

Thanks!

[tommycli, 2015-06-11 17:33:52]

On 2015/06/11 12:46:35, jochen wrote:
> lgtm

jochen: thank you! I realize we've gone back and forth on this for a while,
thanks for stick with it.

[Bernhard Bauer, 2015-06-11 17:43:02]

LGTM

BTW (and sorry, I just realized this now, thinking about the problem a bit
more), if we want to avoid all this Gin weirdness, we could also only expose a
single method that takes an additional parameter, and then in the (single!) C++
implementation of that method dispatch to a different callback based on the
value of that parameter. We'd just have to register the callbacks on a map in
the base class. Now that I think about it, that sounds pretty similar to how
WebUI methods are dispatched...

https://codereview.chromium.org/1161923004/diff/270001/chrome/renderer/plugin...
File chrome/renderer/plugins/chrome_plugin_placeholder.h (right):

https://codereview.chromium.org/1161923004/diff/270001/chrome/renderer/plugin...
chrome/renderer/plugins/chrome_plugin_placeholder.h:75: v8::Isolate* isolate)
final;
Does final imply override?

[tommycli, 2015-06-11 17:46:45]

bauerb: Thanks. Yes what you suggested could let us avoid this gin weirdness. I
will look into that for the next phase of refactoring.

https://codereview.chromium.org/1161923004/diff/270001/chrome/renderer/plugin...
File chrome/renderer/plugins/chrome_plugin_placeholder.h (right):

https://codereview.chromium.org/1161923004/diff/270001/chrome/renderer/plugin...
chrome/renderer/plugins/chrome_plugin_placeholder.h:75: v8::Isolate* isolate)
final;
On 2015/06/11 17:43:02, Bernhard Bauer wrote:
> Does final imply override?

Yes, final implies override. In fact clang-style doesn't let me use both.

[chrishtr, 2015-06-11 20:13:56]

On 2015/06/11 at 17:33:25, tommycli wrote:
> chrishtr: Any objections to the removal of the TestPluginPlaceholder in favor
of the plain PluginPlaceholder?

No.

> bauerb: The plugin placeholder code had to be further changed to avoid the
crashes without making extensive gin::Wrappable changes. Feel free to object /
re-review if you desire.
> 
> Thanks!

[tommycli, 2015-06-11 20:21:37]

The CQ bit was checked by tommycli@chromium.org

[commit-bot: I haz the power, 2015-06-11 20:23:15]

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

[commit-bot: I haz the power, 2015-06-11 20:29:09]

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

[commit-bot: I haz the power, 2015-06-11 20:29:11]

Try jobs failed on following builders:
  linux_chromium_compile_dbg_32_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  ios_dbg_simulator_ninja on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios_dbg_simulator...)
  ios_rel_device_ninja on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios_rel_device_ni...)
  mac_chromium_compile_dbg_ng on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)
  mac_chromium_rel_ng on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[tommycli, 2015-06-11 20:33:22]

The CQ bit was checked by tommycli@chromium.org to run a CQ dry run

[tommycli, 2015-06-11 20:33:22]

The patchset sent to the CQ was uploaded after l-g-t-m from bauerb@chromium.org,
jochen@chromium.org
Link to the patchset: https://codereview.chromium.org/1161923004/#ps310001
(title: "merge origin/master")

[tommycli, 2015-06-11 20:35:45]

The CQ bit was checked by tommycli@chromium.org to run a CQ dry run

[tommycli, 2015-06-11 20:35:46]

The patchset sent to the CQ was uploaded after l-g-t-m from bauerb@chromium.org,
jochen@chromium.org
Link to the patchset: https://codereview.chromium.org/1161923004/#ps330001
(title: "remove some enable_plugins that are no longer needed")

[commit-bot: I haz the power, 2015-06-11 20:36:22]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1161923004/330001

[commit-bot: I haz the power, 2015-06-11 22:08:20]

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

[commit-bot: I haz the power, 2015-06-11 22:08:22]

Dry run: This issue passed the CQ dry run.

[tommycli, 2015-06-11 22:08:51]

The CQ bit was checked by tommycli@chromium.org

[commit-bot: I haz the power, 2015-06-11 22:11:05]

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

[commit-bot: I haz the power, 2015-06-11 22:20:22]

Committed patchset #11 (id:330001)

[commit-bot: I haz the power, 2015-06-11 22:21:48]

Patchset 11 (id:??) landed as
https://crrev.com/425d6965196e7448a2ba9180a3fd2f5b08f5b329
Cr-Commit-Position: refs/heads/master@{#334054}