On Windows.. it dismisses the other bubble instead. On Mac+Views it currently does nothing (other bubble stays open).

Chrome Version       : 64.0.3276.0 

What steps will reproduce the problem?
1. Have two Chrome windows, login to a site for the first time, while the login navigates, select the other window
2. With the second window active, a password bubble should appear on the background window
3. Go to a password field and try to summon the bubble via the location bar icon

What is the expected result?

Bubble should be summoned

What happens instead of that?

Windows: first click dismisses the old bubble. Second click summons.
Mac: button never summons.


It looks like we can't just hide the old bubble in the same event without triggering

[95498:775:1124/145334.324365:FATAL:password_form_metrics_recorder.cc(305)] Check failed: CurrentBubbleOfInterest::kNone == current_bubble_ (0 vs. 1)
0   libbase.dylib                       0x000000011f8163ce base::debug::StackTrace::StackTrace(unsigned long) + 174
1   libbase.dylib                       0x000000011f81648d base::debug::StackTrace::StackTrace(unsigned long) + 29
2   libbase.dylib                       0x000000011f81468c base::debug::StackTrace::StackTrace() + 28
3   libbase.dylib                       0x000000011f8af66f logging::LogMessage::~LogMessage() + 479
4   libbase.dylib                       0x000000011f8ace65 logging::LogMessage::~LogMessage() + 21
5   browser_tests                       0x000000010ce81c8f password_manager::PasswordFormMetricsRecorder::RecordPasswordBubbleShown(password_manager::metrics_util::CredentialSourceType, password_manager::metrics_util::UIDisplayDisposition) + 239
6   browser_tests                       0x000000010dce465c ManagePasswordsBubbleModel::ManagePasswordsBubbleModel(base::WeakPtr<PasswordsModelDelegate>, ManagePasswordsBubbleModel::DisplayReason) + 6700
7   browser_tests                       0x000000010dce50bb ManagePasswordsBubbleModel::ManagePasswordsBubbleModel(base::WeakPtr<PasswordsModelDelegate>, ManagePasswordsBubbleModel::DisplayReason) + 27
8   browser_tests                       0x000000010e44523d ManagePasswordsBubbleView::ManagePasswordsBubbleView(content::WebContents*, views::View*, gfx::Point const&, LocationBarBubbleDelegateView::DisplayReason) + 413
9   browser_tests                       0x000000010e4454e5 ManagePasswordsBubbleView::ManagePasswordsBubbleView(content::WebContents*, views::View*, gfx::Point const&, LocationBarBubbleDelegateView::DisplayReason) + 53
10  browser_tests                       0x000000010e32af0f TabDialogsViewsMac::ShowManagePasswordsBubble(bool) + 703
11  browser_tests                       0x000000010dc73b9f chrome::ManagePasswordsForPage(Browser*) + 111
12  browser_tests                       0x000000010dc6cd39 chrome::BrowserCommandController::ExecuteCommandWithDisposition(int, WindowOpenDisposition) + 4649
13  browser_tests                       0x0000000108052d92 CommandUpdater::ExecuteCommandWithDisposition(int, WindowOpenDisposition) + 114
14  browser_tests                       0x0000000108052d10 CommandUpdater::ExecuteCommand(int) + 32
15  browser_tests                       0x000000010e260b11 ManagePasswordsDecoration::OnMousePressed(CGRect, CGPoint) + 81
16  browser_tests                       0x000000010e24ffda LocationBarDecoration::HandleMousePressed(CGRect, CGPoint) + 234


i.e. if  TabDialogsViewsMac::ShowManagePasswordsBubble() unconditionally calls `HideManagePasswordsBubble()` and then shows a new one, the asynchronous Widget::Close() on the old bubble hasn't completed yet, and this DCHECK is hit.

We can mimic the Windows behaviour in TabDialogsViewsMac (if (showing-on-another-webcontents) HideManagePasswordsBubble(); // return/do nothing). That is, require two clicks as well. But there's probably some race condition lurking here too (e.g. I don't think simply posting a task will do the right thing either).
 

Deleted: bubblenit.mp4 4.2 MB

	bubblenit.mp4 4.2 MB View Download