United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6944561 Mouse cursor stays in Text mode after leaving JTextArea or JTextField (Motif-based Toolkit only)
JDK-6944561 : Mouse cursor stays in Text mode after leaving JTextArea or JTextField (Motif-based Toolkit only)

Details
Type:
Bug
Submit Date:
2010-04-16
Status:
Closed
Updated Date:
2011-02-22
Project Name:
JDK
Resolved Date:
2010-07-22
Component:
client-libs
OS:
solaris
Sub-Component:
java.awt
CPU:
sparc
Priority:
P2
Resolution:
Fixed
Affected Versions:
6u18
Fixed Versions:
6u20-rev (b09)

Related Reports
Backport:
Backport:
Backport:
Relates:

Sub Tasks

Description
With Java SE 6, the mouse cursor stays in Text mode after leaving a JTextField or JTextArea instead of coming back to the deafult arrow cursor. 
This only occurs with Motif-based Toolkit.

                                    

Comments
WORK AROUND

use the XToolkit (default in Java SE 6)
                                     
2010-04-16
EVALUATION

introduced by 4525839.
                                     
2010-05-31
EVALUATION

MToolkit was not implemented in such a way that sun.java2d.Disposer / CursorDisposer methods work for it.
                                     
2010-06-06
SUGGESTED FIX

diff  fix/awt_Cursor.c  src/solaris/native/sun/awt/awt_Cursor.c
109c109
<     (*env)->CallVoidMethod(env, jCur, cursorIDs.mSetPData, (jlong)xcursor);
---
>     (*env)->CallVoidMethod(env, jCur, cursorIDs.mSetPData, xcursor);
                                     
2010-06-24
EVALUATION

4525839 (eliminate use of finalizers) introduced new method setPData (long pData) in class Cursor. In MToolkit it is called from native getCursor() via JNI call:

(*env)->CallVoidMethod(env, jCur, cursorIDs.mSetPData, xcursor);

The problem is xcursor's width, that is 32-bit int. setPData expects 64-bit value as an argument. On little-endian arch the four most significant bytes of parameter receive incorrect values. On big-endian arch xcursor's value is assigned to four most significant bytes of pData, and four least significant bytes receive random values. When pData's value is assigned to 32-bit var again, on big-endian it receives incorrect value from four least significant bytes. Hence, the issue appears on sparc.
                                     
2010-06-24



Hardware and Software, Engineered to Work Together