JDK-6497109 : Dragging mouse out of box for text of TextArea changes mouse cursor (from "beam" to "default")
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 6
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris_9,solaris_10
  • CPU: other,sparc
  • Submitted: 2006-11-24
  • 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 b14Fixed
Related Reports
Duplicate :  
JDK-2150739 - Blocked frame allows the textarea scrollbars to move, when blocked frame is moved in XAWT
Duplicate :  
JDK-6475287 - Scroll bar in TextArea doesn't move when texts in the text area is selected & moved downwards.
Duplicate :  
JDK-6526556 - Blocked frame allows the textarea scrollbars to move, when blocked frame is moved in XAWT
Relates :  
JDK-6429174 - Scroll bar moves when clicked on Intersecting Areas of two Scrollbars in Textarea.
Relates :  
JDK-6530306 - Mouse cursor is not changing to text cursor when the mouse is inside the textarea from jdk6.0 b92
Description
Dragging the mouse from textarea to list changes mouse cursor to default cursor when mouse button is not released.

Step to Reproduce:
-------------------
1) Run the attached program.
2) Move the mouse inside the List. Observe that mouse cursor changes to  "Hand Cursor".
3) Press mouse left button & drag the mouse inside any component on the frame. Observe that mouse cursor remains to "Hand Cursor", till the mouse is released. Its same for all the components.Expect TextArea.
4) Move the mouse inside the textarea. mouse cursor is changed to text cursor ( default cursor). Press mouse left button & drag the mouse inside any component on the frame. Observe that when the mouse is moved over the scrollbar of the textarea , the mouse cursor changes to default cursor. 

If you see the same then the bug is reproduced.
I tested this on Tiger jdk/1.5.0/fcs/b64/ , this works fine. as expected. It even it works fine in Mustang b70( the last build what i have). The last build in mustang i tested is b104. Since i worked fine in tiger & broken in mustang . This is a regression.
Comments
SUGGESTED FIX http://javaweb.sfbay/jcg/7/awt/6497109/
23-05-2007
EVALUATION --- [2007/02/21] I made some corrections and additions to this entry, but main idea remains the same. Don't bother to read this again, unless interested. --- Current implementation logic of setting cursor for TextArea for X is not very easy to fully understand. But I'll try to describe it in brief, for it may help to understand the reason for other bugs. Here it follows: 1. From time to time XTextAreaPeer is asked to set cursor, always to "Text Cursor" (aka "beam"). This cursor gets applied every time, no overriding happens here. 2. Whenever XTextAreaPeer is asked to "handleJavaMouseEvent" (for events like "mouse entered/exited/dragged/moved/pressed/released"), it overrides cursor according to following rules (from now on, by saying 'scrollbar' I will imply '_a_ scrollbar of TextArea'): 2.1. If mouse-pressed or -released event occurs over a scrollbar (its slider or buttons). When mouse gets pressed, XTextAreaPeer enters component-is-grabbed mode. It stays in this mode until mouse-released occurs _over_one_of_scrollbars_! If it is relesed over anything else, component-is-grabbed mode persists. 2.2. If whichever mouse event occurs over box for text, and component-is-grabbed mode is active, then cursor is set to "default". 2.3. If whichever mouse event occurs over box for text, and component-is-grabbed mode is not active, then cursor is set to "text". 2.4. If whichever mouse event occurs over one of scrollbars (including press/resease event, mentioned in 2.1), regardless to component-is-grabbed mode, then cursor is set to "default". 2.5. If whichever mouse event occurs outside box for text, and not over any of scrollbars, and regardless to component-is-grabbed mode, then cursor is set to "default". So, this particular bug (of incorrect changing of cursor from "text" to "default", if mouse if dragged from inside of box for text) corresponds to following 2 scenarios: (i) mouse is pressed inside box for text and dragged onto one of scrollbars, ... then cursor os set to "default" according to 2.4. (ii) mouse is pressed inside box for text and dragged anywhere, except any of scrollbars (remember, by 'scrollbars' I still mean 'TextArea scrollbars'), ... then cursor is set to "deafult" according to 2.5. However, these 2 are not all examples of erroneous cursor setting, caused by current "XTextAreaPeer.handleMouseEvent" logic. There are more. I actually wonder, exactly how many more kinds of misbehaviour can such a small piece of code produce :) BTW, mouse events transferring mechanism is also erroneously affected: - in case 2.2, mouse events are retargeted to a part of scrollbar, over which _mouse_was_pressed_; - in case 2.3, mouse events are retargeted to box for text; - in case 2.4 mouse events are retargeted to a part of scrollbar, over which _mouse_event_occured_; - in case 2.5 mouse events are discarded. So, e.g., case 2.5 makes scrollbars to stop scrolling, if scrollbar is being grabbed, just as mouse passes outside TextArea (or appears over scrollbars "intersection" rectangle). Case 2.4 itself makes mouse events be always retargeted to scrollbars, which is not very good if mouse-grab started e.g. inside box for text. In combination with case 2.5, it prevents text selection from changing, if mouse-grab started inside box for text with some text inside. Finally, I also noticed errors in event-point coordinates translation upon retargeting. E.g.: - events for box for text are shifted +3 pixels (x and y), because viewport shift inside scrollpanel was forgotten; - if event is retargeted to scroll button, then point is translated from scrollpanel directly to button, and intermediate translation to scrollbar-space is missed (, which probably causes scrollbuttons not displaying a visual effect of being pressed). I'm not sure this is all, but don't want to investigate current behavior any more now.
26-01-2007
EVALUATION Actually, the bug I see is that, when mouse is dragged from inside TextArea (not including scroll-bars), cursor is changed to default just as mouse passes outside the box for text (again, not including scroll-bars). So I'm changing synopsis. Old value was "Dragging the mouse from textarea to list changes mouse cursor to default cursor when mouse button" , and was irrelevant even if the bug would really have been about scrollbars (according to description provided).
22-01-2007
EVALUATION Most probably cursor changes are caused by the fix for 6429174. However, befor that fix cursor behaviour also was not completely correct: when I start drags from the text are cursor is a text cursor, then it becomes an arrow cursor (above the textarea's scrollbars) and then changes to a text cursor again (outside of the textarea). So I doubt this bug is a regression.
28-11-2006