United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6431076 Cursor gets reset to text cursor in xawt TextArea when autoscrolling on append
JDK-6431076 : Cursor gets reset to text cursor in xawt TextArea when autoscrolling on append

Details
Type:
Bug
Submit Date:
2006-05-26
Status:
Closed
Updated Date:
2011-03-07
Project Name:
JDK
Resolved Date:
2011-03-07
Component:
client-libs
OS:
solaris_10,windows_xp
Sub-Component:
java.awt
CPU:
x86,sparc
Priority:
P2
Resolution:
Fixed
Affected Versions:
6
Fixed Versions:

Related Reports
Backport:
Duplicate:
Relates:

Sub Tasks

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
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.
                                     
2006-06-16
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.
                                     
2010-11-26
EVALUATION

I could not reproduce the problem with the specified test using jdk 7 release.
                                     
2010-11-29
SUGGESTED FIX

http://sa.sfbay.sun.com/projects/awt_data/7/6431076.3
http://hg.openjdk.java.net/jdk7/awt/jdk/rev/5f3615691623
                                     
2011-01-25



Hardware and Software, Engineered to Work Together