MacViews: Allows the toolkit-views Manage Passwords Dialog to be used

chrome/browser/ui/cocoa/passwords/passwords_bubble_controller_views.mm

Index: chrome/browser/ui/cocoa/passwords/passwords_bubble_controller_views.mm
diff --git a/chrome/browser/ui/cocoa/passwords/passwords_bubble_controller_views.mm b/chrome/browser/ui/cocoa/passwords/passwords_bubble_controller_views.mm
new file mode 100644
index 0000000000000000000000000000000000000000..8106058ce6db25194752e3f19ecace67e05f5bdf
--- /dev/null
+++ b/chrome/browser/ui/cocoa/passwords/passwords_bubble_controller_views.mm
@@ -0,0 +1,45 @@
+// Copyright 2017 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#include "chrome/browser/platform_util.h"
+#include "chrome/browser/ui/browser.h"
+#include "chrome/browser/ui/browser_finder.h"
+#include "chrome/browser/ui/browser_window.h"
+#import "chrome/browser/ui/cocoa/bubble_anchor_helper_views.h"
+#import "chrome/browser/ui/cocoa/passwords/passwords_bubble_controller.h"
+#include "chrome/browser/ui/views/passwords/manage_passwords_bubble_view.h"
+#import "ui/base/cocoa/cocoa_base_utils.h"
+#import "ui/gfx/mac/coordinate_conversion.h"
+
+void ShowViewsManagePasswordsBubbleOnCocoaBrowser(
+    NSPoint anchor,
+    content::WebContents* web_contents,
+    bool user_action) {
+  // Don't show the bubble again if it's already showing. A second click on the
+  // location icon in the omnibox will dismiss an open bubble. This behaviour is
+  // consistent with the non-Mac views implementation.
+  // Note that when the browser is toolkit-views, IsBubbleShown() is checked
+  // earlier because the bubble is shown on mouse release (but dismissed on
+  // mouse pressed). A Cocoa browser does both on mouse pressed, so a check
+  // when showing is sufficient.
+  if (ManagePasswordsBubbleView::IsBubbleShown())

[tapted, 2017/04/12 05:08:42]

Can we get into a situation where this does something unexpected? E.g. if there
are two browser windows, and one has a password bubble visible. initiating a
login in a second browser window shouldn't block the password bubble.

But this should only be an issue if the password bubble persists in some
scenarios, or fails to "steal" focus when it is shown.

[varkha, 2017/04/12 09:16:43]

There shouldn't be non-interactive login, right? And any text input would first
deactivate / hide existing bubble I think.

+    return;
+
+  Browser* browser = chrome::FindBrowserWithWebContents(web_contents);
+  gfx::Point anchor_point =
+      gfx::ScreenPointFromNSPoint(ui::ConvertPointFromWindowToScreen(
+          browser->window()->GetNativeWindow(), anchor));
+  gfx::NativeView parent =
+      platform_util::GetViewForWindow(browser->window()->GetNativeWindow());
+  DCHECK(parent);
+
+  ManagePasswordsBubbleView* bubble_view = new ManagePasswordsBubbleView(
+      web_contents, nullptr, anchor_point,
+      user_action ? LocationBarBubbleDelegateView::USER_GESTURE
+                  : LocationBarBubbleDelegateView::AUTOMATIC);
+  bubble_view->set_parent_window(parent);
+  views::BubbleDialogDelegateView::CreateBubble(bubble_view);
+  bubble_view->GetWidget()->Show();
+  KeepBubbleAnchored(bubble_view);
+}