JDK-6179157 : REGRESSION: Drag N Drop of text does not work on solaris - multi-mon with 2 independent screens
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 5.0
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris_9
  • CPU: sparc
  • Submitted: 2004-10-14
  • Updated: 2011-02-01
  • Resolved: 2005-07-23
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
6 b45Fixed
Related Reports
Relates :  
JDK-6287244 - Linux/Solaris robot should be rewritten
Description
I have multi-monitor setup on solaris configured with 2 independent screens connected to 2 different video boards. I am creating a frame one on each monitor and each of them is having a textarea. I am selecting some text from the source textarea on mon1 and dragging it to the second monitor to drop it in the target textarea located on mon2. But when I drag the text, the mouse does not move to the secondary monitor and it stops at the periphery of the primary one. So could not drag the text across monitors. 

This is reproducible only on solaris and not reproducible on win32, linux + xinerama. This works fine on the previous releases such as 1.4.2, 1.4.1 etc. This is reproducible only since Tiger and hence a regression in tiger. This is reproducible on mustang as well.

I have attached a sample test. Execute the sample test on a solaris (CDE) with multi-mon. 2 frames would appear, one on each of the screens. Select the text from the text area in the mon from which you are running the app and try dragging it to the secondary monitor. If the mouse stops at the periphery of the first monitor, the bug is reproduced.
###@###.### 10/14/04 14:00 GMT

Drag-n-Drop works fine on the same configuration in tiger/mustang when setting the system property "awt.dnd.motifdnd" to true. 
###@###.### 10/15/04 12:03 GMT
###@###.### 10/15/04 12:27 GMT
Comments
SUGGESTED FIX *** /tmp/geta23147 Fri May 6 21:09:41 2005 --- XDragSourceContextPeer.java Fri May 6 17:30:17 2005 *************** *** 169,175 **** 0, GRAB_EVENT_MASK, XlibWrapper.GrabModeAsync, XlibWrapper.GrabModeAsync, ! rootWindow, xcursor, timeStamp); if (status != XlibWrapper.GrabSuccess) { cleanup(timeStamp); --- 169,175 ---- 0, GRAB_EVENT_MASK, XlibWrapper.GrabModeAsync, XlibWrapper.GrabModeAsync, ! XlibWrapper.None, xcursor, timeStamp); if (status != XlibWrapper.GrabSuccess) { cleanup(timeStamp); ###@###.### 2005-05-06 17:19:00 GMT The above fix is for XAWT, the below fix is for MAWT: *** /tmp/geta25727 Mon Jul 11 18:42:50 2005 --- awt_dnd_ds.c Mon Jul 11 18:39:39 2005 *************** *** 1709,1715 **** XSelectInput(awt_display, root_window, your_root_event_mask | ROOT_EVENT_MASK); - /* Confine the pointer to the root window. */ ret = XGrabPointer(awt_display, root_window, False, --- 1709,1714 ---- *************** *** 1716,1722 **** GRAB_EVENT_MASK, GrabModeAsync, GrabModeAsync, ! root_window, xcursor, time_stamp); --- 1715,1721 ---- GRAB_EVENT_MASK, GrabModeAsync, GrabModeAsync, ! None, xcursor, time_stamp); ###@###.### 2005-07-11 14:45:08 GMT
06-05-2005
EVALUATION Our old implementation of Motif dynamic DnD protocol was replaced with new lightweight implementation of Motif DnD protocol and XDND protocol in tiger (4638443:XDND support). Should investigate this regression for mustang. Could the submitter run the test on MTookit with the system property "awt.dnd.motifdnd" set to true and report results? ###@###.### 10/15/04 09:41 GMT The culprit is the call XGrabPointer() with the root window as the parameter confine_to. ###@###.### 2005-05-06 17:19:00 GMT
15-10-2004