JDK-6431076 : Cursor gets reset to text cursor in xawt TextArea when autoscrolling on append
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 6
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris_10,windows_xp
  • CPU: x86,sparc
  • Submitted: 2006-05-26
  • Updated: 2011-03-07
  • Resolved: 2011-03-07
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.
JDK 6 JDK 7
6u10Fixed 7 b130Fixed
Related Reports
Duplicate :  
JDK-6446872 - regression:Pressing any character changes default cursor to Text cursor when the mouse is on the scr
Relates :  
JDK-6459825 - TextArea popupMenu is visible when right clicked on the intersection area of scrollbar
Description
When append call is used on the TextArea, when the mouse cursor is located over a scrollbar, the cursor gets reset to text cursor, even though it should be an arrow over the scrollbar. This is reproducible in xawt only, in Tiger and Mustang.
When xawt TextArea is autoscrolling on appending a newline, ugly flicker happens in the bottom of textarea, and sometimes the bottom part just does not get repainted correctly at all. This is obvious with remote X access, maybe it's less visible with local desktop.

This is reproducible since double-buffering was enabled on used swing components (6352604). Before that, there were multiple flicker problems, but there were no painting erorrs in the bottom of the component.
Comments
SUGGESTED FIX http://sa.sfbay.sun.com/projects/awt_data/7/6431076.3 http://hg.openjdk.java.net/jdk7/awt/jdk/rev/5f3615691623
25-01-2011
EVALUATION I could not reproduce the problem with the specified test using jdk 7 release.
29-11-2010
EVALUATION Unfortunately it doesn't ask a component about the cursor on validation so we don't have a chance to put ours on-the-fly.
26-11-2010
EVALUATION The description of the cause is a bit long, here's the logic of subsequent method calls: 1. append() causes a repaint to be processed 2. Repaint calls the java.awt.Container.validate(), that in turn calls the Component.updateCursorImmediately() method (abbr. upCurImm()). 3. The upCurImm() transfers the call to a peer of the component if and only if the component's peer is not a LightWeightPeer. In the later case it finds out the upper component having a heavyweight peer and calls its upCurImm() method. As far as we use a Swing-component to implement the TextArea under the XToolKit, we have to stick with a LightweightPeer. 4. The upper peer that processes the upCurImm() in our case is the sun.awt.X11.XFramePeer. Its upCurImm() is actually a XComponentPeer's upCurImm() method, that in turn calls the XGlobalCursorManager's upCurImm(), the later calls sun.awt.GlobalCursorManager.upCurImm(), and finally it calls the its _updateCursor() method. And here's the problem: _updateCursor() finds a Heavyweight under the cursor and calls (generic code): setCursor(heavycomp.getCursor()); The heavycomp is the TextArea component, that returns its cursor (the TEXT_CURSOR here). Possible solution: We need to override the getCursor() method in the TextArea component that should check the current toolkit to be the XAWT, and if so transfer the call to the peer's getCursor(). Peer's one should check the current pointer position (to find out is this a scrollbar area under the mouse cursor) and return appropriate cursor.
16-06-2006