[Mac] Enable MacViews bookmark bubble behind --enable-mac-views-dialogs.

[Mac] Enable MacViews bookmark bubble behind --enable-mac-views-dialogs.

This allows BrowserWindowCocoa to show the Views
BookmarkBubbleView.

Similar to WebsiteSettingsPopupView, 
BookmarkBubbleView::ShowBubble() can now take an anchor rect
instead of an anchor View.

This will also use the Views bookmark editor when opened from the
bubble.

In constrained_window::CreateBrowserModalDialogViews, don't 
create a WidgetModalDialogHostObserverViews since the dialog
position is automatically managed by NSWindow.

Closed in favor of: https://codereview.chromium.org/1308713002/

BUG=511051

[jackhou1, 2015-08-20 06:58:20]

jackhou@chromium.org changed reviewers:
+ tapted@chromium.org

[jackhou1, 2015-08-20 06:58:20]

tapted, PTAL

I'll update the CL description with size impact tomorrow (it's compiling).

[tapted, 2015-08-21 00:31:52]

The bubble seems a lot harder than the edit dialog... it's probably justified,
but I think we should split it out to a different CL from the edit dialog if
possible.

i.e. start with just edit dialog, accessible either with (Cocoa versions of)
bookmarks_toolbar->Edit... or bookmark bubble -> Edit...

Then, address the bubble in isolation. Ideally bookmark_bubble_controller.mm
doesn't get involved... Perhaps that means implementing a separate
mac-views-only bridge class (or perhaps that's too hard). Currently there are a
few too many changes to existing classes (i.e. changes we should need to revert
whether we go with mac_views_browser or whether we rollback). The benefit of a
separate bridge class would be that it's clear what code needs to be deleted
once this experiment is over.

https://codereview.chromium.org/1307533002/diff/1/components/constrained_wind...
File components/constrained_window/constrained_window_views.cc (right):

https://codereview.chromium.org/1307533002/diff/1/components/constrained_wind...
components/constrained_window/constrained_window_views.cc:173: return widget;
I know the compiler allows it.. but there's something weird about making the
code below unreachable on mac. Perhaps

#if defined(OS_MACOSX)
  bool requires_positioning = false;
#else
  bool requires_positioning = dialog->UseNewStyleForThisDialog();
#endif

if (!requires_positioning)
  return widget;



But also this will affect the mac_views_browser build, where the code here
currently works OK (I think..). Is mac_views_browser still OK with this change?
What breaks without it? Maybe there's an alternative..

[jackhou1, 2015-08-21 01:55:58]

> The bubble seems a lot harder than the edit dialog... it's probably justified,
> but I think we should split it out to a different CL from the edit dialog if
> possible.
> 
> i.e. start with just edit dialog, accessible either with (Cocoa versions of)
> bookmarks_toolbar->Edit... or bookmark bubble -> Edit...
> 
> Then, address the bubble in isolation. Ideally bookmark_bubble_controller.mm
> doesn't get involved... Perhaps that means implementing a separate
> mac-views-only bridge class (or perhaps that's too hard). Currently there are
a
> few too many changes to existing classes (i.e. changes we should need to
revert
> whether we go with mac_views_browser or whether we rollback). The benefit of a
> separate bridge class would be that it's clear what code needs to be deleted
> once this experiment is over.

Split out bookmark editor changes to https://codereview.chromium.org/1309583002/

BookmarkBubbleController is somewhat coupled with the browser window. This CL
depends on it to lock visibility of the toolbar in fullscreen, and to pulse the
correct item in the bookmark bar. That said, I think we can avoid
BookmarkBubbleController by moving some logic in -startPulsingBookmarkButton: to
BookmarkBarController. I'll get back to you.

https://codereview.chromium.org/1307533002/diff/1/components/constrained_wind...
File components/constrained_window/constrained_window_views.cc (right):

https://codereview.chromium.org/1307533002/diff/1/components/constrained_wind...
components/constrained_window/constrained_window_views.cc:173: return widget;
On 2015/08/21 00:31:52, tapted wrote:
> I know the compiler allows it.. but there's something weird about making the
> code below unreachable on mac. Perhaps
> 
> #if defined(OS_MACOSX)
>   bool requires_positioning = false;
> #else
>   bool requires_positioning = dialog->UseNewStyleForThisDialog();
> #endif
> 
> if (!requires_positioning)
>   return widget;
> 
> 
> 
> But also this will affect the mac_views_browser build, where the code here
> currently works OK (I think..). Is mac_views_browser still OK with this
change?
> What breaks without it? Maybe there's an alternative..

Replied in https://codereview.chromium.org/1309583002/