JDK-6526556 : Blocked frame allows the textarea scrollbars to move, when blocked frame is moved in XAWT
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 6
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: solaris_10
  • CPU: sparc
  • Submitted: 2007-02-20
  • Updated: 2011-01-19
  • Resolved: 2007-10-15
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
6u4Resolved 7Resolved
Related Reports
Duplicate :  
JDK-6497109 - Dragging mouse out of box for text of TextArea changes mouse cursor (from "beam" to "default")
Description
I have textarea which is having some text, when i select the selected & drag the mouse & release it on scrollbar. And when i clicking on the down arrow of the textarea. The text in the textarea are gets selected. The text in the textarea gets selected when the frame is move. This happens only in XToolkit. 
When a modal dialog is visible, it is suppose to block all the user actions on the parent i,e none of the components on the blocked frame should be active & no action should be triggered. But this fails, when the above scenario , is performed on the modal dialog the text in the textarea gets selected. Which gives the impression that blocked allow the text to be selected & allow the scrollbar to move.

 
Step to reproduce:
-------------------
1) Run the attached program.
2) Click on the "File" Menu & Select "Open" Menuitem. 
3) Select any file from the file dialog. The file should contain large data , so that you can see the scrollbar movement.
4) Select some line from the top of the textarea & drag the mouse & release it on scrollbar. 
5) Clicking on the down arrow of the textarea. The text in the textarea are gets selected.
or  when the frame is move the text in the textarea gets selected.
6) Repeat step 2, to invoke the filedialog. Now the frame gets blocked.
7) Repeat step 5. Observe that text in the textarea gets selected & scrollbar moves.

This happens in solaris 10 , I tested this in jdk6.0 & jdk7.0.
Comments
EVALUATION Fixed in 7b14 by fix for CR 6497109 ( Dragging mouse out of box for text of TextArea changes mouse cursor (from "beam" to "default") ). The difference between releasing mouse over a scrollbar or outside of TextArea was left uninvestigated, as I saw no point in doing that now. And the code, which probably caused that difference, is removed by aforementioned fix.
28-06-2007
EVALUATION I'd like to also mention, that it seems to me, that JTextArea behaves strangely in regards to this case. It is obvious, that JTextArea isn't very robust to loosing some mouse events. I mean, if e.g. mouse-released event doesn't pop along, than JTextArea will be likely to "think" it's still being grabbing mouse. Thus, it e.g. will update the text-selection, even if focus is lost long time ago, or if it's modal-blocked, or etc. However, about exactly this problem (how to handle loosing mouse events), it's not clear to me, if or how it can/should be fixed. But there's also one more thing, which I don't yet understand. Consider you are selecting some text in 'java.awt.TextArea', then drag the mouse outside box-for-text, and then release mouse-button. What I don't understand, is why the behavior depends on where you release the button. If you release it not on a TextArea-scrollbar, then this current bug (about updating text selection, if the window is moved) _is_not_reproduced_. But it is reproduced, if you release mouse over one of scrollbars. And it strikes me, that I haven't spotted any difference in mouse-events flow inside JTextArea between there cases.
14-03-2007
EVALUATION I think I completely reproduced the bug. Description was not perfectly clear, so I'm only _almost_ totally sure, that I understood the buggy-case correctly. Problem is very likely to be caused by erroneous dispatching of mouse-events to TextArea's (publicly inaccessible) subcomponents (scrollpane, scrollbars, scrollbuttons, etc.) on X. Anyway, the bug is not reproducible with my fix for CR 6497109 (not yet submitted). That bug is about overriding mouse-cursor, but overriding is embeded into mouse events dispatching, so dispatching is also being correctted (in the context of that CR).
22-02-2007
EVALUATION I couldn't reproduce exactly the problem described, however I have noticed some other strange things. First, I didn't see any events handled by textarea/scrollbar when the modal dialog is shown, however after it is closed, textarea's selection changed. This looks like some of the scrollbar events were enqueued... Second, which is probably the source of the first, is that after the dialog is closed, textarea is always scrolled to the last line, even if I don't touch scrollbar at all. So I consider this a bug with text area.
22-02-2007