Convert DomAutomationController from CppBoundClass to gin::Wrappable

content/renderer/render_view_impl.h

Index: content/renderer/render_view_impl.h
diff --git a/content/renderer/render_view_impl.h b/content/renderer/render_view_impl.h
index f3c8958f5e9d83dc59a6ed4526b4cc1261bc277d..9a4aae3f0eb4247ea11ef1d312f0d89767678d05 100644
--- a/content/renderer/render_view_impl.h
+++ b/content/renderer/render_view_impl.h
@@ -1498,7 +1498,7 @@ class CONTENT_EXPORT RenderViewImpl
 
   // Allows JS to access DOM automation. The JS object is only exposed when the
   // DOM automation bindings are enabled.

[Aaron Boodman, 2014/01/09 20:11:06]

How does RV lifetime relate to frame lifetime, and more specifically this
pointer? Can the JS context shut down making this pointer garbage while RV is
still outstanding?

Either way some comments would be good.

[Aaron Boodman, 2014/01/09 20:19:20]

On second thought, instead of storing this scary looking pointer, what about
stashing DomAutomatonController in JS-land instead, via
frame->context()->global()->SetHiddenValue()?

On the other hand, it looks like this pointer is never used except as a flag as
to whether the controller has been installed already. In that case, maybe we
shouldn't store it at all, but rather actually look in the JS context and see if
it's there. Or store a boolean did_install_ instead?

[jochen (gone - plz use gerrit), 2014/01/09 20:30:38]

I think I'll just install one controller per frame and don't keep a reference to
it at all

-  scoped_ptr<DomAutomationController> dom_automation_controller_;
+  DomAutomationController* dom_automation_controller_;
 
   // This field stores drag/drop related info for the event that is currently
   // being handled. If the current event results in starting a drag/drop