This is more accurately a P1. 

On Windows this dialog goes away just by holding ctrl (for ctrl+t to open a new tab). If we click on the tab strip to open a new tab goes away from the mousedown (regardless of clicking new tab or just anywhere outside the widget).

How are you opening the new tab? Mouse or keyboard shortcut?

+tapted@, +ellyjones@ is there a broader set of issues with widgets not being dismissed on Mac here?

Keyboard shortcut in the example. It doesn't go away when holding ctrl (on Mac). 
You're correct, mouse down anywhere in the UI removes the UI. 

If you bring the dialog up yourself on Windows (click the translate icon for instance), then ctrl+t gets eaten by the dialog so the tabs don't open. Do you mean that the dialog doesn't go away when you click ctrl or do you mean ⌘? Tab opens with ⌘ on Mac right?

It might be that this dialog's WebContentsObserver (or somehow through a parent class) should implement some of:

  virtual void WasShown() {}
  virtual void WasHidden() {}

To hide the dialog when the web contents are hidden (maybe show it again when the tab comes back, I dunno?). I assume web contents are hidden == tab is not visible and that there's normally only one web contents instance showing per browser window.

I don't think we're shipping #enable-translate-new-ux on Mac in m66 -- plan is to keep using an infobar until we have fewer moving parts.

This fix is could be very similar to https://chromium-review.googlesource.com/c/chromium/src/+/848113

note the call to TranslateBubbleView::CloseCurrentBubble() in the nearby diff of browser_view.cc -- Mac isn't using browser_view.cc yet, so is missing this CloseCurrentBubble call.

But translate should not be coupled to browser_view.cc in this way. That CL decoupled the zoom bubble, but not the translate bubble.

I think we might be at a point where LocationBarBubbleDelegateView should just become a WebContentsObserver. It already takes a web_contents in its constructor. 

https://chromium-review.googlesource.com/c/chromium/src/+/862966 would benefit from this as well.

@c6: re "I don't think we're shipping #enable-translate-new-ux on Mac in m66." 
That's not what ellyjones told me when I last checked. Elly, can you comment? We've been operating under the assumption that we're switching to the bubble on Mac in 66.

Re: c5
Sorry I mis-spoke. The dialog doesnt go away when I click ⌘. Creating a new tab on Mac consists of ⌘ + T. 

#6: what are the moving parts? My current plan (as per #7) is to work with the translate team to flip #enable-translate-new-ux on M66, although I think the translate team owns actually doing any necessary code/experiment changes. Is there a reason we should not do that?

Elly - when you say the Translate team, do you mean the Chrome Language team? This is all news to me. I was under the impression that the MacViews team was handling all of this, akin to how the Harmony changes to Translate UIs were all done by the Harmony team.  Perhaps it's best you and I, as well as Anthony, Chrome Language's new TL and only team member right now (as of today) should sync offline?

Yes, good idea - I've booked us a meeting.

Anthony - will the focus issue be addressed by the other changes you're making to the bubble on Mac?

Ah! Unfortunately no, I wasn't aware of this issue. I made the other changes and called it done for now, and 66 is already branched.

I can take a look at this later this week to see how much effort is required and whether a merge to 66 is realistic/needed. Sounds good?

Yep, thanks. Ironically this slipped in our convo with Elly since this is what precipitated the discussion in the first place. I was triaging bugs and noticed it this morning.

If the patch isn't too complicated I don't think a merge is unrealistic, we're still early past branch point and this is very user visible imo.

This no longer replicates - I believe a separate change fixed the behavior. Can someone from test verify?