Disables showing tooltips while a system menu is showing on windows

ui/aura/client/tooltip_client.h

 // 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.
 
 #ifndef UI_AURA_CLIENT_TOOLTIP_CLIENT_H_
 #define UI_AURA_CLIENT_TOOLTIP_CLIENT_H_
 
 #include "ui/aura/aura_export.h"
 #include "ui/gfx/font.h"
 
 namespace aura {
 class Window;
 namespace client {
 
+class ScopedTooltipDisabler;
+
 class AURA_EXPORT TooltipClient {
  public:
   // Informs the shell tooltip manager of change in tooltip for window |target|.
   virtual void UpdateTooltip(Window* target) = 0;
 
   // Sets the time after which the tooltip is hidden for Window |target|. If
   // |timeout_in_ms| is <= 0, the tooltip is shown indefinitely.
   virtual void SetTooltipShownTimeout(Window* target, int timeout_in_ms) = 0;
 
-  // Enables/Disables tooltips.
+ protected:
+  // Enables/Disables tooltips. This is treated as a reference count. Consumers

[varunjain, 2014/01/07 05:07:06]

I am not sure how much the ScopedDisabler buys. I am not opposed to to it, but I
would have just created a static void SetTooltipsEnabled(Window* window, bool
enable), same as Set/GetTooltipText() below. That way, you do not need to add an
observer.
I think I am not sure what sort of errors are you trying to protect against. Are
you worried that the root window might change between a disable and enable? If
so, first, I do not see what situation that could happen in and second, even if
it happens, ScopedDisabler in its current form is not set up to re-enable the
tooltip of the old root window and disable for the new root.

[sky, 2014/01/07 16:52:03]

RWHVA may move between root windows. You are correct that ScopedDisabler doesn't
entirely deal with this situation, but at least it does not have the possibility
of disabling on one and then reenabling on the wrong root.

My assumption here is that if you've moving the window to a different root
you'll recreate the scoper. But worse case you don't, the code won't cause any
problems.

[varunjain, 2014/01/08 15:43:09]

But in that case, the ScopedDisabler is even more incorrect. Consider for
example, two roots R1 and R2 with RWHV1 and RWHV2 respectively. Both use scoped
disabler to disable tooltips. Now both switch root windows so RWHV1 is in R2 and
RWHV2 is in R1. Now if say RWHV1 tries to enable tooltips by resetting scoped
disabler, it will enable R1's tooltips.
The code will cause the problem I described above (although arguably its a
degenerate case). Previous code would have just enabled the tooltip in the right
root window.

+  // must use ScopedTooltipDisabler to enable/disabled tooltips.
   virtual void SetTooltipsEnabled(bool enable) = 0;
+
+ private:
+  friend class ScopedTooltipDisabler;
 };
 
 AURA_EXPORT void SetTooltipClient(Window* root_window,
                                   TooltipClient* client);
 AURA_EXPORT TooltipClient* GetTooltipClient(Window* root_window);
 
 AURA_EXPORT void SetTooltipText(Window* window, base::string16* tooltip_text);
 AURA_EXPORT const base::string16 GetTooltipText(Window* window);
 
 }  // namespace client
 }  // namespace aura
 
 #endif  // UI_AURA_CLIENT_TOOLTIP_CLIENT_H_