Don't add an aura tooltip to bubble close buttons on Windows.

ui/views/bubble/bubble_frame_view.cc

Index: ui/views/bubble/bubble_frame_view.cc
diff --git a/ui/views/bubble/bubble_frame_view.cc b/ui/views/bubble/bubble_frame_view.cc
index dff1e993c38982f0e6869eebfe6b7b7a9b7b85c6..39fa447528b3256ebf51e1152d5f5f037ea90f62 100644
--- a/ui/views/bubble/bubble_frame_view.cc
+++ b/ui/views/bubble/bubble_frame_view.cc
@@ -125,8 +125,6 @@ gfx::Rect BubbleFrameView::GetWindowBoundsForClientBounds(
 int BubbleFrameView::NonClientHitTest(const gfx::Point& point) {
   if (!bounds().Contains(point))
     return HTNOWHERE;
-  if (close_->visible() && close_->GetMirroredBounds().Contains(point))
-    return HTCLOSE;

[msw, 2015/03/31 16:45:30]

Hmm, do screen readers, software that assists the visually impaired, or 3rd
party windowing enhancement software (WindowBlinds, etc.) rely on this?
+CC Dominic, Scott, and Peter for any thoughts on this.

[dmazzoni, 2015/03/31 16:55:46]

Yes, they do call hit testing functions so at first glance this might be an
issue.

Can you think of an alternative fix, or do we need to dig into this some more to
see how much of a problem it is?

[msw, 2015/03/31 16:57:22]

We could hide the other tooltip when the native one will be shown.

[benwells, 2015/03/31 22:06:57]

I think that would look like adding an #if !defined(OS_WIN) around the
SetToolTip call.

I have a feeling this is the only place in Chrome that the native tooltip comes
up.

Do we have a11y problems with the aura tooltip? Meaning, in other places where
we use the aura tooltip (like bookmarks, chrome://apps, and everywhere else that
uses tooltips) are there a11y problems?

[msw, 2015/03/31 22:11:26]

What do browser frames do? Those seem to show native tooltips for their caption
buttons. Gating on OS_WIN (and desktop/ash_shell?) might be ok.

[benwells, 2015/04/08 00:19:13]

Ah, yes the frames use the native hint as well. I'd say that is the same
mechanism: windows automatically adding a native tooltop based on hit testing.

That doesn't seem so bad as the frame looks like a part of windows, so having
the native tooltip is ok. But these dialog close buttons don't feel like part of
windows so it would be nice if they were consistent with all the other tooltips.

But it probably doesn't matter that much.

I'll look at (a) can the native tooltip be suppressed while still returning
HTCLOSE, and if that doesn't work (b) I'll add some conditional around setting
the tooltip.

 
   // Allow dialogs to show the system menu and be dragged.
   if (GetWidget()->widget_delegate()->AsDialogDelegate()) {