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

ui/views/bubble/bubble_frame_view.cc

 // Copyright (c) 2012 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 "ui/views/bubble/bubble_frame_view.h"
 
 #include <algorithm>
 
 #include "ui/base/hit_test.h"
 #include "ui/base/l10n/l10n_util.h"
@@ skipping 107 matching lines @@
 
 gfx::Rect BubbleFrameView::GetWindowBoundsForClientBounds(
     const gfx::Rect& client_bounds) const {
   return const_cast<BubbleFrameView*>(this)->GetUpdatedWindowBounds(
       gfx::Rect(), client_bounds.size(), false);
 }
 
 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()) {
     gfx::Rect sys_rect(0, 0, title_->x(), title_->y());
     sys_rect.set_origin(gfx::Point(GetMirroredXForRect(sys_rect), 0));
     if (sys_rect.Contains(point))
       return HTSYSMENU;
     if (point.y() < title_->bounds().bottom())
       return HTCAPTION;
   }
@@ skipping 284 matching lines @@
   if (titlebar_extra_view_ != NULL)
     title_bar_width += titlebar_extra_view_->GetPreferredSize().width();
   gfx::Size size(client_size);
   size.SetToMax(gfx::Size(title_bar_width, 0));
   const gfx::Insets insets(GetInsets());
   size.Enlarge(insets.width(), insets.height());
   return size;
 }
 
 }  // namespace views