Use MacViews for ContentSettingBubbles.

chrome/browser/ui/views/content_setting_bubble_contents.cc

Index: chrome/browser/ui/views/content_setting_bubble_contents.cc
diff --git a/chrome/browser/ui/views/content_setting_bubble_contents.cc b/chrome/browser/ui/views/content_setting_bubble_contents.cc
index 6f454c1466cffd994c9a48afddc44bf66f18c925..12b5210277f4751291ffd08edc3c2bc88983f4d6 100644
--- a/chrome/browser/ui/views/content_setting_bubble_contents.cc
+++ b/chrome/browser/ui/views/content_setting_bubble_contents.cc
@@ -15,6 +15,7 @@
 #include "base/strings/utf_string_conversions.h"
 #include "chrome/browser/plugins/plugin_finder.h"
 #include "chrome/browser/plugins/plugin_metadata.h"
+#include "chrome/browser/ui/browser_dialogs.h"
 #include "chrome/browser/ui/content_settings/content_setting_bubble_model.h"
 #include "chrome/browser/ui/content_settings/content_setting_media_menu_model.h"
 #include "chrome/browser/ui/views/browser_dialogs.h"
@@ -498,3 +499,20 @@ void ContentSettingBubbleContents::UpdateMenuButtonSizes() {
     i->first->SetMaxSize(gfx::Size(menu_width, 0));
   }
 }
+
+namespace chrome {
+
+void ContentSettingBubbleViewsBridge::Show(gfx::NativeView parent_view,

[tapted, 2016/01/11 23:21:38]

Can this go in c/b/ui/views/browser_dialog_views_mac.cc - this would make it
clear that it's something we can remove once the browser window is no longer
Cocoa

[Elly Fong-Jones, 2016/01/12 14:09:59]

Done.

+                                           ContentSettingBubbleModel* model,
+                                           content::WebContents* web_contents,
+                                           const gfx::Point& anchor) {
+  ContentSettingBubbleContents* contents =
+      new ContentSettingBubbleContents(model, web_contents, nullptr,
+          views::BubbleBorder::Arrow::TOP_RIGHT);
+  contents->set_parent_window(parent_view);
+  contents->SetAnchorRect(gfx::Rect(anchor, gfx::Size()));
+  // TODO(ellyjones): why doesn't this leak the bubble?

[tapted, 2016/01/11 23:21:39]

Yeah it's spooky isn't it.. Probably CreateBubble should take a scoped_ptr (or
at least say that it assumes ownership). Instead it takes a
`BubbleDelegateView`, which inherits from views::View. Views tend to quickly get
inserted into a View hierarchy which transfers ownership to the root view of the
Widget, but scoped_ptrs haven't caught on -- it would make a lot of the UI code
really clumsy. So there's a convention among toolkit-views UI code that things
inheriting from a views::View* just use raw pointers and you "should" always
plonk them into a view hierarchy before the method returns.

Where the ownership is actually transferred is by (also) setting the
BubbleDelegateView as the Widget delegate, and providing an override for
`GetContentsView`.

Then if you look in  Widget::Init(..), you can see it will either make a `new
NonClientView` and set that as the ContentsView, or set the ContentsView from
delegate->GetContentsView(). BubbleDelegateView::GetContentsView() doesn't
allocate with `new` -- it just returns `this` and so it effectively provides
that `new ContentSettingBubbleContents` that happens just above this line in
place of the `new NonClientView` that Widget::Init would do otherwise.

[Elly Fong-Jones, 2016/01/12 14:09:59]

Ick. Ack.

+  views::BubbleDelegateView::CreateBubble(contents)->Show();
+}
+
+}  // namespace chrome