JDK-4148057 : Using ToolTips causes inactive app window to exhibit active window behavior
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 1.1.6,1.2.0,1.4.0,1.4.1
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_95,windows_2000,windows_xp
  • CPU: x86
  • Submitted: 1998-06-11
  • Updated: 2003-03-20
  • Resolved: 2003-03-12
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
5.0 tigerFixed
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Description

Name: el35337			Date: 06/11/98


========== to reproduce ========
- compile single source file included below
- run application:  java TipTest
- when app window appears, position another
  application (e.g. Win95 calculator) so that
  it is active, and partially obscures the 
  TipTest app window, like this:


   .....................
   |     TipTest       |
   |               .................
   |      *        |
   |               |   Calculator
   ................| (or other app)
                   |
                   .................  

- position the mouse (hover over but do
  NOT click) somewhere to the left of the
  calculator app. (approx. in area marked
  by the '*' character above).  At this
  point, the calculator app should STILL
  be the active window.

====== the bugs ================
BUG A
  as you rest the mouse cursor over
  the area shown above, the ToolTip will 
  appear, even though the TipTest 
  window/app is inactive.  This
  seems wrong.  The TipTest app/window 
  should NOT be processing mouse events
  (until the window is made active again).
  For an example of standard Windows behavior, 
  look at Netscape Communicator toolbar.  When
  another app is active in front of Communicator,
  Communicator's toolbar buttons ignore
  mouse "rollover" events.

BUG B
  Bug B happens because of Bug A.  With the
  mouse cursor resting over the area marked '*',
  wait for the ToolTip to display.  Then move the
  mouse slowly down toward the bottom edge of
  the frame, again WITHOUT any mouse clicks.
  When the mouse cursor crosses the frame's
  bottom edge, the TipTest app/window is 
  repainted and brought to the FRONT of the 
  Calculator app, as though TipTest had been 
  made active.  However, it is not active, as
  the colors of the two applications title bars
  remain as they were.  Also, any keystrokes are
  processed by the calculator program.

========== source ==============

import com.sun.java.swing.*;
import java.awt.event.*;
import java.awt.*;
import java.lang.*;

public class TipTest extends JPanel
{
    public TipTest()
    {
        setToolTipText("");
        setBackground(Color.white);
    }

    public static void main(String argv[])
    {
        JFrame f = new JFrame("Tooltip Bug Example");
        TipTest p = new TipTest();

        f.setDefaultCloseOperation(JFrame.DO_NOTHING_ON_CLOSE);
        f.getContentPane().add(p);
        f.setSize(new Dimension(350,250));
        f.setVisible(true);
    }

    public String getToolTipText(MouseEvent e)
    {
        return "( x="+e.getX()+",y="+e.getY()+")";
    }

}
(Review ID: 33521)
======================================================================

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger FIXED IN: tiger INTEGRATED IN: tiger tiger-b03
24-08-2004

EVALUATION Name: apR10133 Date: 11/24/2000 ToolTipManager never checks if the tooltip should appears in focused frame or no. We can make this check for frames. The part B of description is not reproducible since 1.2 ###@###.### ====================================================================== Because of the problems with fix for 4250178 I had to backed out fix for this one. reopening the bug ###@###.### 2002-04-23 Name: apR10133 Date: 04/24/2002 There is no problems with the fix for 4250178. Actually the problem is for fix for this bug (#4148057). The fix is inaccurate: it doesn't terminate the cycle when it find the first Window at the hierarchy if this Window is focused. It cause to the situation when the floating toolbar window is active, but cycle wasn't terminated at the proper time and find the toolbar's parent frame (main frame), which is not currently focused (and hence tooltip isn't shown). See the suggested fix for the proper fix. ###@###.### ======================================================================
24-08-2004

SUGGESTED FIX Name: apR10133 Date: 11/24/2000 ------- ToolTipManager.java ------- *** /tmp/sccs.gfaGwV Fri Nov 24 19:36:30 2000 --- ToolTipManager.java Fri Nov 24 19:36:22 2000 *************** *** 246,251 **** --- 246,259 ---- void showTipWindow() { if(insideComponent == null || !insideComponent.isShowing()) return; + for (Container p = insideComponent.getParent(); p != null; p = p.getParent()) { + if (p instanceof Window && !((Window)p).isFocused()) { + return; + } + if (p instanceof Applet) { + break; + } + } if (enabled) { Dimension size; Point screenLocation = insideComponent.getLocationOnScreen(); ###@###.### ====================================================================== Name: apR10133 Date: 04/24/2002 ------- ToolTipManager.java ------- *** /tmp/sccs.18aODJ Wed Apr 24 14:58:26 2002 --- ToolTipManager.java Wed Apr 24 14:57:59 2002 *************** *** 242,247 **** --- 242,258 ---- void showTipWindow() { if(insideComponent == null || !insideComponent.isShowing()) return; + for (Container p = insideComponent.getParent(); p != null; p = p.getParent()) { + if (p instanceof Window) { + if (!((Window)p).isFocused()) { + return; + } + break; + } + if (p instanceof Applet) { + break; + } + } if (enabled) { Dimension size; Point screenLocation = insideComponent.getLocationOnScreen(); ###@###.### ====================================================================== The above fix does not cover those problems occuring with Java applets. One of the cases where bug B occurs filed as a separate bug - #4832671. See #4832671 Suggested Fix for details. ###@###.### 2003-03-14
14-03-2003