Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

drag and drop support #770

Closed
totaam opened this issue Jan 2, 2015 · 45 comments
Closed

drag and drop support #770

totaam opened this issue Jan 2, 2015 · 45 comments

Comments

@totaam
Copy link
Collaborator

totaam commented Jan 2, 2015 •
edited
Loading

At the very least, we should support drag and drop within the same application, since all this stays server side.

If we do support some form of remote to local drag and drop (ie: dropping a URL on a browser), we may want to include some form of filtering, like the clipboard filter file.

I'm not sure if we want to use GTK for this, it may just end up getting in the way, just like it did with clipboard - with which it shares a lot of concepts (selections, conversions, etc). Still useful for a quick test application.

Some pointers:
@totaam
Copy link
Collaborator Author

totaam commented Jan 5, 2015

2015-01-05 07:30:32: antoine uploaded file Dropper.java (5.7 KiB)

a simple Java app which accepts drops and shows the flavors available

@totaam
Copy link
Collaborator Author

totaam commented Jan 14, 2015

2015-01-14 10:05:16: antoine uploaded file VeryBasicDnD.java (6.1 KiB)

updated example code

@totaam
Copy link
Collaborator Author

totaam commented Jan 14, 2015

2015-01-14 12:41:35: antoine commented

Right, so this works... but only some of the time!

x11trace (excerpts):

  • working case:
000:<:0326:  8: Request(27): UngrabPointer time=CurrentTime(0x00000000)
000:<:0327:  8: Request(32): UngrabKeyboard time=CurrentTime(0x00000000)
000:<:0328: 24: Request(26): GrabPointer owner-events=false(0x00) grab-window=0x00000044 event-mask=ButtonPress,ButtonRelease,ButtonMotion,VisibilityChange,OwnerGrabButton pointer-mode=Asynchronous(0x01) 
keyboard-mode=Asynchronous(0x01) confine-to=None(0x00000000) cursor=0x0080003e time=0x02088077
000:>:0328: Event LeaveNotify(8) detail=Ancestor(0x00) mode=Grab(0x01) flags=same-screen time=0x0208808f root=0x00000044 event=0x0080000e child=None(0x00000000) root-x=99 root-y=125 event-x=99 event-y=97 
state=Mod2,Button1
000:>:0328: Event LeaveNotify(8) detail=Virtual(0x01) mode=Grab(0x01) flags=same-screen time=0x0208808f root=0x00000044 event=0x00800007 child=0x0080000e root-x=99 root-y=125 event-x=95 event-y=69 state=M
od2,Button1
000:>:0328:32: Reply to GrabPointer: status=Success(0x00)
000:<:0329: 16: Request(31): GrabKeyboard grab-window=0x00000044 time=0x02088077 pointer-mode=Asynchronous(0x01) keyboard-mode=Asynchronous(0x01)
000:>:0329: Event FocusOut(10) detail=Ancestor(0x00) event=0x00800010 mode=Grab(0x01)
000:>:0329:32: Reply to GrabKeyboard: status=Success(0x00)
000:>:0329: Event MotionNotify(6) detail=Normal(0x00) time=0x0208809d root=0x00000044 event=0x00000044 child=0x0040002b root-x=100 root-y=125 event-x=100 event-y=125 state=Mod2,Button1 same-screen=true(0x
01)
000:<:032a: 24: Request(20): GetProperty delete=false(0x00) window=0x0040002b property=0x128("WM_STATE") type=0x128("WM_STATE") long-offset=0x00000000 long-length=0x00000001
000:>:032a:32: Reply to GetProperty: type=None(0x0) bytes-after=0x00000000 
000:>:032a: Event MotionNotify(6) detail=Normal(0x00) time=0x0208809f root=0x00000044 event=0x00000044 child=0x0040002b root-x=103 root-y=125 event-x=103 event-y=125 state=Mod2,Button1 same-screen=true(0x
01)
000:<:032b:  8: Request(15): QueryTree window=0x0040002b
000:>:032b:44: Reply to QueryTree: root=0x00000044 parent=0x00000044 children=0x0040002c,0x0040003b,0x004003f8;
000:>:032b: Event MotionNotify(6) detail=Normal(0x00) time=0x020880a2 root=0x00000044 event=0x00000044 child=0x0040002b root-x=104 root-y=125 event-x=104 event-y=125 state=Mod2,Button1 same-screen=true(0x
01)
000:<:032c: 24: Request(20): GetProperty delete=false(0x00) window=0x004003f8 property=0x128("WM_STATE") type=0x128("WM_STATE") long-offset=0x00000000 long-length=0x00000001
000:>:032c:32: Reply to GetProperty: type=None(0x0) bytes-after=0x00000000 
000:<:032d:  8: Request(15): QueryTree window=0x004003f8
000:>:032d:36: Reply to QueryTree: root=0x00000044 parent=0x0040002b children=;
000:<:032e: 24: Request(20): GetProperty delete=false(0x00) window=0x00800007 property=0x17b("XdndAware") type=any(0x0) long-offset=0x00000000 long-length=0x00000001
000:>:032e:36: Reply to GetProperty: type=0x4("ATOM") bytes-after=0x00000000 data=;
000:<:032f: 24: Request(20): GetProperty delete=false(0x00) window=0x00800007 property=0x17c("XdndProxy") type=0x21("WINDOW") long-offset=0x00000000 long-length=0x00000001
000:>:032f:32: Reply to GetProperty: type=None(0x0) bytes-after=0x00000000 
000:<:0330: 44: Request(25): SendEvent propagate=false(0x00) destination=0x00800007 event-mask=0 ClientMessage(33) format=0x20 window=0x00800007 type=0x17e("XdndEnter") data=0x08,0x00,0x80,0x00,0x01,0x00,
0x00,0x05,0xe2,0x00,0x00,0x00,0xaf,0x01,0x00,0x00,0x1f,0x00,0x00,0x00;
000:<:0331: 44: Request(25): SendEvent propagate=false(0x00) destination=0x00800007 event-mask=0 ClientMessage(33) format=0x20 window=0x00800007 type=0x17f("XdndPosition") data=0x08,0x00,0x80,0x00,0x00,0x
00,0x00,0x00,0x7d,0x00,0x64,0x00,0x9d,0x80,0x08,0x02,0x76,0x01,0x00,0x00;
000:<:0332: 44: Request(25): SendEvent propagate=false(0x00) destination=0x00800007 event-mask=0 ClientMessage(33) format=0x20 window=0x00800007 type=0x17f("XdndPosition") data=0x08,0x00,0x80,0x00,0x00,0x
00,0x00,0x00,0x7d,0x00,0x67,0x00,0x9f,0x80,0x08,0x02,0x76,0x01,0x00,0x00;
  • non-working case:
000:<:02b2:  8: Request(27): UngrabPointer time=CurrentTime(0x00000000)
000:<:02b3:  8: Request(32): UngrabKeyboard time=CurrentTime(0x00000000)
000:<:02b4: 24: Request(26): GrabPointer owner-events=false(0x00) grab-window=0x00000044 event-mask=ButtonPress,ButtonRelease,ButtonMotion,VisibilityChange,OwnerGrabButton pointer-mode=Asynchronous(0x01) keyboard-mode=Asynchronous(0x01) confine-to=None(0x00000000) cursor=0x0080003a time=0x020eba0a
000:>:02b4: Event LeaveNotify(8) detail=Ancestor(0x00) mode=Grab(0x01) flags=same-screen time=0x020eba1e root=0x00000044 event=0x0080000e child=None(0x00000000) root-x=53 root-y=123 event-x=53 event-y=95 state=Mod2,Button1
000:>:02b4: Event LeaveNotify(8) detail=Virtual(0x01) mode=Grab(0x01) flags=same-screen time=0x020eba1e root=0x00000044 event=0x00800007 child=0x0080000e root-x=53 root-y=123 event-x=49 event-y=67 state=Mod2,Button1
000:>:02b4:32: Reply to GrabPointer: status=Success(0x00)
000:>:02b4: Event MotionNotify(6) detail=Normal(0x00) time=0x020eba1e root=0x00000044 event=0x00000044 child=0x0040002b root-x=61 root-y=124 event-x=61 event-y=124 state=Mod2,Button1 same-screen=true(0x01)
000:<:02b5: 16: Request(31): GrabKeyboard grab-window=0x00000044 time=0x020eba0a pointer-mode=Asynchronous(0x01) keyboard-mode=Asynchronous(0x01)
000:>:02b5: Event FocusOut(10) detail=Ancestor(0x00) event=0x00800010 mode=Grab(0x01)
000:>:02b5:32: Reply to GrabKeyboard: status=Success(0x00)
000:<:02b6: 24: Request(20): GetProperty delete=false(0x00) window=0x0040002b property=0x128("WM_STATE") type=0x128("WM_STATE") long-offset=0x00000000 long-length=0x00000001
000:>:02b6:32: Reply to GetProperty: type=None(0x0) bytes-after=0x00000000 
000:<:02b7:  8: Request(15): QueryTree window=0x0040002b
000:>:02b7:44: Reply to QueryTree: root=0x00000044 parent=0x00000044 children=0x0040002c,0x0040003b,0x00400406;
000:<:02b8: 24: Request(20): GetProperty delete=false(0x00) window=0x0040003b property=0x128("WM_STATE") type=0x128("WM_STATE") long-offset=0x00000000 long-length=0x00000001
000:>:02b8:32: Reply to GetProperty: type=None(0x0) bytes-after=0x00000000 
000:<:02b9:  8: Request(15): QueryTree window=0x0040003b
000:>:02b9:36: Reply to QueryTree: root=0x00000044 parent=0x0040002b children=;
000:<:02ba: 24: Request(20): GetProperty delete=false(0x00) window=0x00600022 property=0x128("WM_STATE") type=0x128("WM_STATE") long-offset=0x00000000 long-length=0x00000001
000:>:02ba:36: Reply to GetProperty: type=0x128("WM_STATE") bytes-after=0x00000000 data=0x00000001;
000:<:02bb: 24: Request(20): GetProperty delete=false(0x00) window=0x00600022 property=0x17b("XdndAware") type=any(0x0) long-offset=0x00000000 long-length=0x00000001
000:>:02bb:32: Reply to GetProperty: type=None(0x0) bytes-after=0x00000000 
000:<:02bc: 24: Request(20): GetProperty delete=false(0x00) window=0x00600022 property=0x189("_MOTIF_DRAG_RECEIVER_INFO") type=any(0x0) long-offset=0x00000000 long-length=0x0000ffff
000:>:02bc:32: Reply to GetProperty: type=None(0x0) bytes-after=0x00000000 
000:>:02bc: Event MotionNotify(6) detail=Normal(0x00) time=0x020eba34 root=0x00000044 event=0x00000044 child=0x0040002b root-x=63 root-y=124 event-x=63 event-y=124 state=Mod2,Button1 same-screen=true(0x01)
000:>:02bc: Event MotionNotify(6) detail=Normal(0x00) time=0x020eba35 root=0x00000044 event=0x00000044 child=0x0040002b root-x=64 root-y=124 event-x=64 event-y=124 state=Mod2,Button1 same-screen=true(0x01)
000:>:02bc: Event MotionNotify(6) detail=Normal(0x00) time=0x020eba5b root=0x00000044 event=0x00000044 child=0x0040002b root-x=66 root-y=124 event-x=66 event-y=124 state=Mod2,Button1 same-screen=true(0x01)

Looks like the DND code picks the wrong window sometimes (ie below: the xterm I launch from), and then decides that DND is not supported.
This probably comes from QueryTree.

  • bad case:
Xpra-WorldWindow
Xpra-CorralWindow-0x600022" (xterm)
  • good case:
Xpra-WorldWindow
"no-name" (Java event window)
Xpra-CorralWindow-0xc00007" (Java)
  • another good case:
Xpra-WorldWindow
Xpra-CorralWindow-0xc00007" (Java)

Which looks like it is coming from or somewhere near XDragSourceContextPeer which eventually calls down to [http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/sun/awt/X11/XlibUtil.java]'s getChildWindows (which uses a set, which is not ordered and would explain the randomness aspect).

@totaam
Copy link
Collaborator Author

totaam commented Jan 15, 2015

2015-01-15 08:22:53: antoine commented

After building Java from source with home made patches to add extra logging, I can see:

  • non working trace:
Jan 15, 2015 1:07:29 PM sun.awt.X11.XDropTargetRegistry getToplevelWindow
INFO: getToplevelWindow(800007) candWindow=sun.awt.X11.XFramePeer@2032e1d1(800007)
Jan 15, 2015 1:07:29 PM sun.awt.X11.XDropTargetRegistry getToplevelWindow
INFO: toplevel=sun.awt.X11.XFramePeer@2032e1d1(800007)
Jan 15, 2015 1:07:29 PM sun.awt.X11.XDropTargetRegistry getToplevelWindow
INFO: returning toplevel.getWindow()=8388615
Jan 15, 2015 1:07:29 PM sun.awt.X11.XDropTargetRegistry updateEmbedderDropSite
INFO: updateEmbedderDropSite(800007) xbaseWindow=sun.awt.X11.XFramePeer@2032e1d1(800007)
getSourceActions(javax.swing.JList[,5,24,334x51,alignmentX=0.0,alignmentY=0.0,border=,flags=50331944,maximumSize=,minimumSize=,preferredSize=,fixedCellHeight=-1,fixedCellWidth=-1,horizontalScrollIncrement=-1,selectionBackground=javax.swing.plaf.ColorUIResource[r=184,g=207,b=229],selectionForeground=sun.swing.PrintColorUIResource[r=51,g=51,b=51],visibleRowCount=0,layoutOrientation=0])
getSourceActions(javax.swing.JList[,5,24,334x51,alignmentX=0.0,alignmentY=0.0,border=,flags=50331944,maximumSize=,minimumSize=,preferredSize=,fixedCellHeight=-1,fixedCellWidth=-1,horizontalScrollIncrement=-1,selectionBackground=javax.swing.plaf.ColorUIResource[r=184,g=207,b=229],selectionForeground=sun.swing.PrintColorUIResource[r=51,g=51,b=51],visibleRowCount=0,layoutOrientation=0])
getSourceActions(javax.swing.JList[,5,24,334x51,alignmentX=0.0,alignmentY=0.0,border=,flags=50331944,maximumSize=,minimumSize=,preferredSize=,fixedCellHeight=-1,fixedCellWidth=-1,horizontalScrollIncrement=-1,selectionBackground=javax.swing.plaf.ColorUIResource[r=184,g=207,b=229],selectionForeground=sun.swing.PrintColorUIResource[r=51,g=51,b=51],visibleRowCount=0,layoutOrientation=0])
createTransferable(javax.swing.JList[,5,24,334x51,alignmentX=0.0,alignmentY=0.0,border=,flags=50331944,maximumSize=,minimumSize=,preferredSize=,fixedCellHeight=-1,fixedCellWidth=-1,horizontalScrollIncrement=-1,selectionBackground=javax.swing.plaf.ColorUIResource[r=184,g=207,b=229],selectionForeground=sun.swing.PrintColorUIResource[r=51,g=51,b=51],visibleRowCount=0,layoutOrientation=0])
StringSelection(Item 2)
Jan 15, 2015 1:07:30 PM sun.awt.X11.XDragSourceContextPeer startDrag
INFO: startDrag(java.awt.datatransfer.StringSelection@61304000, [226, 407, 31, 409, 410, 411, 412, 413, 414, 415, 408], {226=java.awt.datatransfer.DataFlavor[mimetype=application/x-java-serialized-object;representationclass=java.lang.String], 407=java.awt.datatransfer.DataFlavor[mimetype=application/x-java-serialized-object;representationclass=java.lang.String], 31=java.awt.datatransfer.DataFlavor[mimetype=application/x-java-serialized-object;representationclass=java.lang.String], 409=java.awt.datatransfer.DataFlavor[mimetype=application/x-java-serialized-object;representationclass=java.lang.String], 410=java.awt.datatransfer.DataFlavor[mimetype=application/x-java-serialized-object;representationclass=java.lang.String], 411=java.awt.datatransfer.DataFlavor[mimetype=application/x-java-serialized-object;representationclass=java.lang.String], 412=java.awt.datatransfer.DataFlavor[mimetype=application/x-java-serialized-object;representationclass=java.lang.String], 413=java.awt.datatransfer.DataFlavor[mimetype=application/x-java-serialized-object;representationclass=java.lang.String], 414=java.awt.datatransfer.DataFlavor[mimetype=application/x-java-serialized-object;representationclass=java.lang.String], 415=java.awt.datatransfer.DataFlavor[mimetype=application/x-java-serialized-object;representationclass=java.lang.String], 408=java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=java.io.InputStream;charset=unicode]})
Jan 15, 2015 1:07:30 PM sun.awt.X11.XDragSourceContextPeer startDrag
INFO: startDrag: dragWindow=800008, dropActions=1, rootWindow=44
Jan 15, 2015 1:07:30 PM sun.awt.X11.XDragSourceContextPeer startDrag
INFO: startDrag: dragProtocol=sun.awt.X11.XDnDDragSourceProtocol@23b2a3b8
Jan 15, 2015 1:07:30 PM sun.awt.X11.XDragSourceContextPeer startDrag
INFO: startDrag: dragProtocol=sun.awt.X11.MotifDnDDragSourceProtocol@ce76ef6
Jan 15, 2015 1:07:31 PM sun.awt.X11.XDragSourceContextPeer processMouseMove
INFO: processMouseMove(XMotionEvent # typeMotionNotify, serial # 658, send_eventfalse, display # 140270009602512, window44, root # 68, subwindow4194347, time # 8290765, x95, y # 105, x_root95, y_root # 105, state272, is_hint # 0, same_screentrue, ) dragInProgress=true
Jan 15, 2015 1:07:31 PM sun.awt.X11.XDragSourceContextPeer processMouseMove
INFO: postDragSourceDragEvent: MOUSE_MOVED
Jan 15, 2015 1:07:31 PM sun.awt.X11.XDragSourceContextPeer processMouseMove
INFO: postDragSourceDragEvent: state changed from 272 to 0, calling updateSourceAction
Jan 15, 2015 1:07:31 PM sun.awt.X11.XDragSourceContextPeer updateTargetWindow
INFO: updateTargetWindow(XMotionEvent # typeMotionNotify, serial # 658, send_eventfalse, display # 140270009602512, window44, root # 68, subwindow4194347, time # 8290765, x95, y # 105, x_root95, y_root # 105, state272, is_hint # 0, same_screentrue, ) dragProtocol=null, targetRootSubwindow=0, subwindow=40002b
Jan 15, 2015 1:07:31 PM sun.awt.X11.XDragSourceContextPeer findClientWindow
INFO: findClientWindow(40002b) children=[40002c, 40003b, 400447]
Jan 15, 2015 1:07:31 PM sun.awt.X11.XDragSourceContextPeer findClientWindow
INFO: findClientWindow(40002c) children=[]
Jan 15, 2015 1:07:31 PM sun.awt.X11.XDragSourceContextPeer findClientWindow
INFO: findClientWindow(..) not found!
Jan 15, 2015 1:07:31 PM sun.awt.X11.XDragSourceContextPeer findClientWindow
INFO: findClientWindow(40003b) children=[600022]
Jan 15, 2015 1:07:31 PM sun.awt.X11.XDragSourceContextPeer findClientWindow
INFO: findClientWindow(600022) is true toplevel
Jan 15, 2015 1:07:31 PM sun.awt.X11.XDragSourceContextPeer findClientWindow
INFO: findClientWindow(..)=600022
Jan 15, 2015 1:07:31 PM sun.awt.X11.XDragSourceContextPeer findClientWindow
INFO: findClientWindow(..)=600022
Jan 15, 2015 1:07:31 PM sun.awt.X11.XDragSourceContextPeer processMouseMove
INFO: processMouseMove(XMotionEvent # typeMotionNotify, serial # 658, send_eventfalse, display # 140270009602512, window44, root # 68, subwindow4194347, time # 8290765, x100, y # 105, x_root100, y_root # 105, state272, is_hint # 0, same_screentrue, ) dragInProgress=true
Jan 15, 2015 1:07:31 PM sun.awt.X11.XDragSourceContextPeer processMouseMove
INFO: postDragSourceDragEvent: MOUSE_MOVED
Jan 15, 2015 1:07:31 PM sun.awt.X11.XDragSourceContextPeer updateTargetWindow
INFO: updateTargetWindow(XMotionEvent # typeMotionNotify, serial # 658, send_eventfalse, display # 140270009602512, window44, root # 68, subwindow4194347, time # 8290765, x100, y # 105, x_root100, y_root # 105, state272, is_hint # 0, same_screentrue, ) dragProtocol=null, targetRootSubwindow=40002b, subwindow=40002b
Jan 15, 2015 1:07:31 PM sun.awt.X11.XDragSourceContextPeer processMouseMove
INFO: processMouseMove(XMotionEvent # typeMotionNotify, serial # 658, send_eventfalse, display # 140270009602512, window44, root # 68, subwindow4194347, time # 8290766, x105, y # 105, x_root105, y_root # 105, state272, is_hint # 0, same_screentrue, ) dragInProgress=true
Jan 15, 2015 1:07:31 PM sun.awt.X11.XDragSourceContextPeer processMouseMove
INFO: postDragSourceDragEvent: MOUSE_MOVED
Jan 15, 2015 1:07:31 PM sun.awt.X11.XDragSourceContextPeer updateTargetWindow
INFO: updateTargetWindow(XMotionEvent # typeMotionNotify, serial # 658, send_eventfalse, display # 140270009602512, window44, root # 68, subwindow4194347, time # 8290766, x105, y # 105, x_root105, y_root # 105, state272, is_hint # 0, same_screentrue, ) dragProtocol=null, targetRootSubwindow=40002b, subwindow=40002b
Jan 15, 2015 1:07:31 PM sun.awt.X11.XDragSourceContextPeer processMouseMove
INFO: processMouseMove(XMotionEvent # typeMotionNotify, serial # 658, send_eventfalse, display # 140270009602512, window44, root # 68, subwindow4194347, time # 8290766, x111, y # 105, x_root111, y_root # 105, state272, is_hint # 0, same_screentrue, ) dragInProgress=true
Jan 15, 2015 1:07:31 PM sun.awt.X11.XDragSourceContextPeer processMouseMove
INFO: postDragSourceDragEvent: MOUSE_MOVED
Jan 15, 2015 1:07:31 PM sun.awt.X11.XDragSourceContextPeer updateTargetWindow
INFO: updateTargetWindow(XMotionEvent # typeMotionNotify, serial # 658, send_eventfalse, display # 140270009602512, window44, root # 68, subwindow4194347, time # 8290766, x111, y # 105, x_root111, y_root # 105, state272, is_hint # 0, same_screentrue, ) dragProtocol=null, targetRootSubwindow=40002b, subwindow=40002b
Jan 15, 2015 1:07:31 PM sun.awt.X11.XDragSourceContextPeer processMouseMove
INFO: processMouseMove(XMotionEvent # typeMotionNotify, serial # 658, send_eventfalse, display # 140270009602512, window44, root # 68, subwindow4194347, time # 8290766, x116, y # 105, x_root116, y_root # 105, state272, is_hint # 0, same_screentrue, ) dragInProgress=true
Jan 15, 2015 1:07:31 PM sun.awt.X11.XDragSourceContextPeer processMouseMove
INFO: postDragSourceDragEvent: MOUSE_MOVED
  • working trace:
Jan 15, 2015 1:02:53 PM sun.awt.X11.XDropTargetRegistry getToplevelWindow
INFO: getToplevelWindow(800007) candWindow=sun.awt.X11.XFramePeer@2032e1d1(800007)
Jan 15, 2015 1:02:53 PM sun.awt.X11.XDropTargetRegistry getToplevelWindow
INFO: toplevel=sun.awt.X11.XFramePeer@2032e1d1(800007)
Jan 15, 2015 1:02:53 PM sun.awt.X11.XDropTargetRegistry getToplevelWindow
INFO: returning toplevel.getWindow()=8388615
Jan 15, 2015 1:02:53 PM sun.awt.X11.XDropTargetRegistry updateEmbedderDropSite
INFO: updateEmbedderDropSite(800007) xbaseWindow=sun.awt.X11.XFramePeer@2032e1d1(800007)
getSourceActions(javax.swing.JList[,5,24,334x51,alignmentX=0.0,alignmentY=0.0,border=,flags=50331944,maximumSize=,minimumSize=,preferredSize=,fixedCellHeight=-1,fixedCellWidth=-1,horizontalScrollIncrement=-1,selectionBackground=javax.swing.plaf.ColorUIResource[r=184,g=207,b=229],selectionForeground=sun.swing.PrintColorUIResource[r=51,g=51,b=51],visibleRowCount=0,layoutOrientation=0])
getSourceActions(javax.swing.JList[,5,24,334x51,alignmentX=0.0,alignmentY=0.0,border=,flags=50331944,maximumSize=,minimumSize=,preferredSize=,fixedCellHeight=-1,fixedCellWidth=-1,horizontalScrollIncrement=-1,selectionBackground=javax.swing.plaf.ColorUIResource[r=184,g=207,b=229],selectionForeground=sun.swing.PrintColorUIResource[r=51,g=51,b=51],visibleRowCount=0,layoutOrientation=0])
getSourceActions(javax.swing.JList[,5,24,334x51,alignmentX=0.0,alignmentY=0.0,border=,flags=50331944,maximumSize=,minimumSize=,preferredSize=,fixedCellHeight=-1,fixedCellWidth=-1,horizontalScrollIncrement=-1,selectionBackground=javax.swing.plaf.ColorUIResource[r=184,g=207,b=229],selectionForeground=sun.swing.PrintColorUIResource[r=51,g=51,b=51],visibleRowCount=0,layoutOrientation=0])
createTransferable(javax.swing.JList[,5,24,334x51,alignmentX=0.0,alignmentY=0.0,border=,flags=50331944,maximumSize=,minimumSize=,preferredSize=,fixedCellHeight=-1,fixedCellWidth=-1,horizontalScrollIncrement=-1,selectionBackground=javax.swing.plaf.ColorUIResource[r=184,g=207,b=229],selectionForeground=sun.swing.PrintColorUIResource[r=51,g=51,b=51],visibleRowCount=0,layoutOrientation=0])
StringSelection(Item 3)
Jan 15, 2015 1:02:55 PM sun.awt.X11.XDragSourceContextPeer startDrag
INFO: startDrag(java.awt.datatransfer.StringSelection@61304000, [226, 407, 31, 409, 410, 411, 412, 413, 414, 415, 408], {226=java.awt.datatransfer.DataFlavor[mimetype=application/x-java-serialized-object;representationclass=java.lang.String], 407=java.awt.datatransfer.DataFlavor[mimetype=application/x-java-serialized-object;representationclass=java.lang.String], 31=java.awt.datatransfer.DataFlavor[mimetype=application/x-java-serialized-object;representationclass=java.lang.String], 409=java.awt.datatransfer.DataFlavor[mimetype=application/x-java-serialized-object;representationclass=java.lang.String], 410=java.awt.datatransfer.DataFlavor[mimetype=application/x-java-serialized-object;representationclass=java.lang.String], 411=java.awt.datatransfer.DataFlavor[mimetype=application/x-java-serialized-object;representationclass=java.lang.String], 412=java.awt.datatransfer.DataFlavor[mimetype=application/x-java-serialized-object;representationclass=java.lang.String], 413=java.awt.datatransfer.DataFlavor[mimetype=application/x-java-serialized-object;representationclass=java.lang.String], 414=java.awt.datatransfer.DataFlavor[mimetype=application/x-java-serialized-object;representationclass=java.lang.String], 415=java.awt.datatransfer.DataFlavor[mimetype=application/x-java-serialized-object;representationclass=java.lang.String], 408=java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=java.io.InputStream;charset=unicode]})
Jan 15, 2015 1:02:55 PM sun.awt.X11.XDragSourceContextPeer startDrag
INFO: startDrag: dragWindow=800008, dropActions=1, rootWindow=44
Jan 15, 2015 1:02:55 PM sun.awt.X11.XDragSourceContextPeer startDrag
INFO: startDrag: dragProtocol=sun.awt.X11.XDnDDragSourceProtocol@23b2a3b8
Jan 15, 2015 1:02:55 PM sun.awt.X11.XDragSourceContextPeer startDrag
INFO: startDrag: dragProtocol=sun.awt.X11.MotifDnDDragSourceProtocol@ce76ef6
Jan 15, 2015 1:02:55 PM sun.awt.X11.XDragSourceContextPeer processMouseMove
INFO: processMouseMove(XMotionEvent # typeMotionNotify, serial # 630, send_eventfalse, display # 140602735480256, window44, root # 68, subwindow4194347, time # 8015604, x83, y # 120, x_root83, y_root # 120, state272, is_hint # 0, same_screentrue, ) dragInProgress=true
Jan 15, 2015 1:02:55 PM sun.awt.X11.XDragSourceContextPeer processMouseMove
INFO: postDragSourceDragEvent: MOUSE_MOVED
Jan 15, 2015 1:02:55 PM sun.awt.X11.XDragSourceContextPeer processMouseMove
INFO: postDragSourceDragEvent: state changed from 272 to 0, calling updateSourceAction
Jan 15, 2015 1:02:55 PM sun.awt.X11.XDragSourceContextPeer updateTargetWindow
INFO: updateTargetWindow(XMotionEvent # typeMotionNotify, serial # 630, send_eventfalse, display # 140602735480256, window44, root # 68, subwindow4194347, time # 8015604, x83, y # 120, x_root83, y_root # 120, state272, is_hint # 0, same_screentrue, ) dragProtocol=null, targetRootSubwindow=0, subwindow=40002b
Jan 15, 2015 1:02:55 PM sun.awt.X11.XDragSourceContextPeer findClientWindow
INFO: findClientWindow(40002b) children=[40002c, 4003d6, 40003b]
Jan 15, 2015 1:02:55 PM sun.awt.X11.XDragSourceContextPeer findClientWindow
INFO: findClientWindow(40002c) children=[]
Jan 15, 2015 1:02:55 PM sun.awt.X11.XDragSourceContextPeer findClientWindow
INFO: findClientWindow(..) not found!
Jan 15, 2015 1:02:55 PM sun.awt.X11.XDragSourceContextPeer findClientWindow
INFO: findClientWindow(4003d6) children=[800007]
Jan 15, 2015 1:02:55 PM sun.awt.X11.XDragSourceContextPeer findClientWindow
INFO: findClientWindow(800007) is true toplevel
Jan 15, 2015 1:02:55 PM sun.awt.X11.XDragSourceContextPeer findClientWindow
INFO: findClientWindow(..)=800007
Jan 15, 2015 1:02:55 PM sun.awt.X11.XDragSourceContextPeer findClientWindow
INFO: findClientWindow(..)=800007
Jan 15, 2015 1:02:55 PM sun.awt.X11.XDragSourceContextPeer doUpdateTargetWindow
INFO: doUpdateTargetWindow(40002b, 8015604) attached using sun.awt.X11.XDnDDragSourceProtocol@23b2a3b8
Jan 15, 2015 1:02:55 PM sun.awt.X11.XDragSourceContextPeer updateTargetWindow
INFO: sendEnterMessage
Jan 15, 2015 1:02:55 PM sun.awt.X11.XDragSourceContextPeer processMouseMove
INFO: postDragSourceDragEvent: sendMoveMessage
Jan 15, 2015 1:02:55 PM sun.awt.X11.XDragSourceContextPeer processMouseMove
INFO: processMouseMove(XMotionEvent # typeMotionNotify, serial # 630, send_eventfalse, display # 140602735480256, window44, root # 68, subwindow4194347, time # 8015604, x88, y # 120, x_root88, y_root # 120, state272, is_hint # 0, same_screentrue, ) dragInProgress=true
Jan 15, 2015 1:02:55 PM sun.awt.X11.XDragSourceContextPeer processMouseMove
INFO: postDragSourceDragEvent: MOUSE_MOVED
Jan 15, 2015 1:02:55 PM sun.awt.X11.XDragSourceContextPeer updateTargetWindow
INFO: updateTargetWindow(XMotionEvent # typeMotionNotify, serial # 630, send_eventfalse, display # 140602735480256, window44, root # 68, subwindow4194347, time # 8015604, x88, y # 120, x_root88, y_root # 120, state272, is_hint # 0, same_screentrue, ) dragProtocol=sun.awt.X11.XDnDDragSourceProtocol@23b2a3b8, targetRootSubwindow=40002b, subwindow=40002b
Jan 15, 2015 1:02:55 PM sun.awt.X11.XDragSourceContextPeer processMouseMove
INFO: postDragSourceDragEvent: sendMoveMessage
Jan 15, 2015 1:02:55 PM sun.awt.X11.XDragSourceContextPeer processMouseMove
INFO: processMouseMove(XMotionEvent # typeMotionNotify, serial # 630, send_eventfalse, display # 140602735480256, window44, root # 68, subwindow4194347, time # 8015605, x93, y # 122, x_root93, y_root # 122, state272, is_hint # 0, same_screentrue, ) dragInProgress=true
Jan 15, 2015 1:02:55 PM sun.awt.X11.XDragSourceContextPeer processMouseMove
INFO: postDragSourceDragEvent: MOUSE_MOVED
Jan 15, 2015 1:02:55 PM sun.awt.X11.XDragSourceContextPeer updateTargetWindow
INFO: updateTargetWindow(XMotionEvent # typeMotionNotify, serial # 630, send_eventfalse, display # 140602735480256, window44, root # 68, subwindow4194347, time # 8015605, x93, y # 122, x_root93, y_root # 122, state272, is_hint # 0, same_screentrue, ) dragProtocol=sun.awt.X11.XDnDDragSourceProtocol@23b2a3b8, targetRootSubwindow=40002b, subwindow=40002b
Jan 15, 2015 1:02:55 PM sun.awt.X11.XDragSourceContextPeer processMouseMove
INFO: postDragSourceDragEvent: sendMoveMessage
Jan 15, 2015 1:02:55 PM sun.awt.X11.XDragSourceContextPeer processMouseMove
INFO: processMouseMove(XMotionEvent # typeMotionNotify, serial # 630, send_eventfalse, display # 140602735480256, window44, root # 68, subwindow4194347, time # 8015608, x100, y # 124, x_root100, y_root # 124, state272, is_hint # 0, same_screentrue, ) dragInProgress=true
Jan 15, 2015 1:02:55 PM sun.awt.X11.XDragSourceContextPeer processMouseMove
INFO: postDragSourceDragEvent: MOUSE_MOVED
Jan 15, 2015 1:02:55 PM sun.awt.X11.XDragSourceContextPeer updateTargetWindow
INFO: updateTargetWindow(XMotionEvent # typeMotionNotify, serial # 630, send_eventfalse, display # 140602735480256, window44, root # 68, subwindow4194347, time # 8015608, x100, y # 124, x_root100, y_root # 124, state272, is_hint # 0, same_screentrue, ) dragProtocol=sun.awt.X11.XDnDDragSourceProtocol@23b2a3b8, targetRootSubwindow=40002b, subwindow=40002b
Jan 15, 2015 1:02:55 PM sun.awt.X11.XDragSourceContextPeer processMouseMove
INFO: postDragSourceDragEvent: sendMoveMessage
canImport(javax.swing.TransferHandler$TransferSupport@6b573212)
canImport(javax.swing.TransferHandler$TransferSupport@6b573212)
canImport(javax.swing.TransferHandler$TransferSupport@6b573212)
canImport(javax.swing.TransferHandler$TransferSupport@6b573212)
Jan 15, 2015 1:02:55 PM sun.awt.X11.XDragSourceContextPeer processMouseMove
INFO: processMouseMove(XMotionEvent # typeMotionNotify, serial # 652, send_eventfalse, display # 140602735480256, window44, root # 68, subwindow4194347, time # 8015635, x107, y # 124, x_root107, y_root # 124, state272, is_hint # 0, same_screentrue, ) dragInProgress=true
Jan 15, 2015 1:02:55 PM sun.awt.X11.XDragSourceContextPeer processMouseMove
INFO: postDragSourceDragEvent: MOUSE_MOVED

I think TILS are:

INFO: updateTargetWindow(XMotionEvent # typeMotionNotify, serial # 658, send_eventfalse, display # 140270009602512, window44, root # 68, subwindow4194347, time # 8290765, x95, y # 105, x_root95, y_root # 105, state272, is_hint # 0, same_screentrue, ) dragProtocol=null, targetRootSubwindow=0, subwindow=40002b
Jan 15, 2015 1:07:31 PM sun.awt.X11.XDragSourceContextPeer findClientWindow
INFO: findClientWindow(40002b) children=[40002c, 40003b, 400447]
Jan 15, 2015 1:07:31 PM sun.awt.X11.XDragSourceContextPeer findClientWindow
INFO: findClientWindow(40002c) children=[]
Jan 15, 2015 1:07:31 PM sun.awt.X11.XDragSourceContextPeer findClientWindow
INFO: findClientWindow(..) not found!
Jan 15, 2015 1:07:31 PM sun.awt.X11.XDragSourceContextPeer findClientWindow
INFO: findClientWindow(40003b) children=[600022]
Jan 15, 2015 1:07:31 PM sun.awt.X11.XDragSourceContextPeer findClientWindow
INFO: findClientWindow(600022) is true toplevel
Jan 15, 2015 1:07:31 PM sun.awt.X11.XDragSourceContextPeer findClientWindow
INFO: findClientWindow(..)=600022
Jan 15, 2015 1:07:31 PM sun.awt.X11.XDragSourceContextPeer findClientWindow
INFO: findClientWindow(..)=600022

vs

INFO: updateTargetWindow(XMotionEvent # typeMotionNotify, serial # 630, send_eventfalse, display # 140602735480256, window44, root # 68, subwindow4194347, time # 8015604, x83, y # 120, x_root83, y_root # 120, state272, is_hint # 0, same_screentrue, ) dragProtocol=null, targetRootSubwindow=0, subwindow=40002b
Jan 15, 2015 1:02:55 PM sun.awt.X11.XDragSourceContextPeer findClientWindow
INFO: findClientWindow(40002b) children=[40002c, 4003d6, 40003b]
Jan 15, 2015 1:02:55 PM sun.awt.X11.XDragSourceContextPeer findClientWindow
INFO: findClientWindow(40002c) children=[]
Jan 15, 2015 1:02:55 PM sun.awt.X11.XDragSourceContextPeer findClientWindow
INFO: findClientWindow(..) not found!
Jan 15, 2015 1:02:55 PM sun.awt.X11.XDragSourceContextPeer findClientWindow
INFO: findClientWindow(4003d6) children=[800007]
Jan 15, 2015 1:02:55 PM sun.awt.X11.XDragSourceContextPeer findClientWindow
INFO: findClientWindow(800007) is true toplevel
Jan 15, 2015 1:02:55 PM sun.awt.X11.XDragSourceContextPeer findClientWindow
INFO: findClientWindow(..)=800007
Jan 15, 2015 1:02:55 PM sun.awt.X11.XDragSourceContextPeer findClientWindow
INFO: findClientWindow(..)=800007
Jan 15, 2015 1:02:55 PM sun.awt.X11.XDragSourceContextPeer doUpdateTargetWindow
INFO: doUpdateTargetWindow(40002b, 8015604) attached using sun.awt.X11.XDnDDragSourceProtocol@23b2a3b8
Jan 15, 2015 1:02:55 PM sun.awt.X11.XDragSourceContextPeer updateTargetWindow
INFO: sendEnterMessage

I am stumped. (and also found a bug with xkbmap_mod_pointermissing... see 8479)

@totaam
Copy link
Collaborator Author

totaam commented Jan 15, 2015 •
edited
Loading

Since Java calls findClientWindow on the window it gets from the XMotionEvent, I thought that maybe we were somehow using the wrong window when generating the mouse motion events. So the patch above replaces the GTK calls with relative motion events, which could be useful for #137 and may be worth applying in any case, after cleaning it up.
But that doesn't seem to change the window id that Java sees, and it then still picks the wrong window half the time!

This patch is really ugly and broken, we can probably skip a lot of the messy logic and just rely on X11Keyboard.window_at_pointer to return None if we're not in the window we are looking for? Needs testing with OR windows, etc.

It is worth mentioning that GTK's window_at_pointer does not seem to work properly, it doesn't seem to be aware of the window size changes... Which could be causing us other problems elsewhere (focus, geometry, events..).

@totaam
Copy link
Collaborator Author

totaam commented Jan 15, 2015

2015-01-15 12:31:58: antoine uploaded file relative-motion.patch (5.1 KiB)

hackish patch for testing relative motion events

@totaam
Copy link
Collaborator Author

totaam commented Jan 16, 2015 •
edited
Loading

Well, in the end, I refused to let this bug go, I just could not see any way of getting Java to not traverse the window tree all the way up to the world window (which then causes it to pick the wrong window as target), so r8484 completely changes the way windows are organized: they are now all children of the root window and the "world window" is just another window. This matches what other window managers do, and does not seem to have any other negative impacts. It is also cleaner / makes more sense.

I guess it could be backported to v0.14.x eventually, after a long time settling in the 0.15 branch.

afarr: this one is a BIG FYI, it is a very significant change. Which could potentially cause us some focus problems (or maybe even fixes for existing problems!).

@totaam
Copy link
Collaborator Author

totaam commented Jan 16, 2015

2015-01-16 10:18:16: antoine uploaded file java-debug.patch (12.3 KiB)

extra logging that I've used to help diagnose what Java is doing

@totaam
Copy link
Collaborator Author

totaam commented Jan 23, 2015 •
edited
Loading

Tested (perhaps redundantly) successfully with windows 0.15.0 8522 and OSX 0.15.0 8527 against fedora 20 0.15.0 8527 - quite a success (I remember this was breaking browsers at one point).

Nice work!

Closing (but I'll watch for focus issues that might relate).

@totaam
Copy link
Collaborator Author

totaam commented Feb 9, 2015

2015-02-09 07:30:14: antoine commented

This change has now been in trunk for a month and nothing seems to have been broken by it, so I have backported it in 8644.

@totaam
Copy link
Collaborator Author

totaam commented Feb 14, 2015

2015-02-14 04:34:51: antoine commented

Just got an email from Calvin saying that this was causing problems in 0.14.x, so it looks like this will need to be reverted before the release.

@totaam
Copy link
Collaborator Author

totaam commented Feb 16, 2015

2015-02-16 18:02:59: afarr commented

It's odd...

  • Testing with your fedora 20 0.14.19 dist against my osx 0.14.20 r8648 build client, the drop downs work as expected (and the drag and drop seems to be working with cursory tests as well).

  • Testing with our builds on fedora 20 servers (0.14.20 each side), the drop downs seem to work as expected (and again, drag and drop seems to be working with cursory tests as well).

  • Testing with the same server/client versions on our fedora 21 servers seems to introduce non-interactive drop menu items (mouse non-interactive, acturally... they do work with keyboard commands, with down/up arrow keys and an enter key).

I'll see about pinning this down some more (I really would rather not disable drag and drop if possible).

@totaam
Copy link
Collaborator Author

totaam commented Feb 19, 2015

2015-02-19 22:23:54: afarr commented

OK, confirmed... I'm seeing drop menu issues with trunk builds on fedora 20 and 21 servers, with both windows and osx clients. The issues seem to be different from browser to browser (what a surprise!), but the same between fedora 20 servers and fedora 21 and between osx and windows clients.

windows client (8.1) 0.15.0 8647 (smo's build)
osx client 0.15.0 r8640 (my build)
fedora 20 0.15.0 r8661 (your beta build)
fedora 21 0.15.0 r8661 (also your beta build)

  • With firefox, clicking on a drop down menu then attempting to use mouse to make a selection - the drop menu popsup, but there's no indication that the mouse movements are being read, and trying to click on an option (not highlighted) closes the drop menu with no other effect. (Problem we had seen. Apparently we had some trunk code in our 14.19 server/clients?)
  • With firefox, clicking and holding on a drop menu, and mousing down highlights drop menu selections as expected, and un-clicking works as expected.
  • With epiphany - clicking on a drop down menu, whether the click is held or un-clicked, the drop menu displays but no selections highlight and neither clicking again nor un-clicking (in the case of a held click) triggers any selection, though in both cases the drop menu is closed.

I grabbed some logs, both with windows and osx clients... will attach probably (hopefully) more than you need.

The interesting part, as far as I can tell, from the windows connection to the fedora 21 server using epiphany is this:

2015-02-19 12:43:40,411 _button_action(1, <gtk.gdk.Event at 076BF530: GDK_BUTTON_PRESS x=801.00, y=354.00, button=1>, True) wid=5 / focus=5, pointer=(2081, 354), modifiers=['mod2'], buttons=[]
2015-02-19 12:43:40,443 process_new_common: [17, 1946, 348, 199, 173, {'opacity': -1, 'fullscreen': False, 'has-alpha': True, 'xid': '0xa00cb3', 'pid': 19251, 'window-type': ('POPUP_MENU',), 'maximized': False, 'override-redirect': True}], OR=True
2015-02-19 12:43:40,443 make_new_window(..) client_window_classes=[<class 'xpra.client.gl.gtk2.gl_client_window.GLClientWindow'>, <class 'xpra.client.gtk2.border_client_window.BorderClientWindow'>], group_leader_window=<gtk.gdk.Window object at 0x77d6e90 (GdkWindow at 0x22f29a0)>
2015-02-19 12:43:40,443 GLClientWindow(..)
2015-02-19 12:43:40,443 <class 'xpra.client.gl.gtk2.gl_client_window.GLClientWindow'>(gtk2.client, <gtk.gdk.Window object at 0x77d6e90 (GdkWindow at 0x22f29a0)>, 17, 1946, 348, 199, 173, {'opacity': -1, 'fullscreen': False, 'has-alpha': True, 'xid': '0xa00cb3', 'pid': 19251, 'window-type': ('POPUP_MENU',), 'maximized': False, 'override-redirect': True}, True, {}, (0, 0))
2015-02-19 12:43:40,443 set_window_type(['POPUP_MENU']) hints=9
2015-02-19 12:43:40,443 new_backing(199, 173) backing_class=<class 'xpra.client.gl.gtk2.gl_window_backing.GLPixmapBacking'>
2015-02-19 12:43:40,443 make_new_backing(<class 'xpra.client.gl.gtk2.gl_window_backing.GLPixmapBacking'>, 199, 173) effective backing class=<class 'xpra.client.gl.gtk2.gl_window_backing.GLPixmapBacking'>, server alpha=True, window alpha=False
2015-02-19 12:43:40,443 Win32Hooks: window frame size is 8x8
2015-02-19 12:43:40,443 failed to set group leader: 'module' object has no attribute 'SHGetPropertyStoreForWindow'
2015-02-19 12:43:40,443 GL do_configure_event(<gtk.gdk.Event at 0758A050: GDK_CONFIGURE x=1946, y=348, width=199, height=173>)
2015-02-19 12:43:40,443 GL do_configure_event(<gtk.gdk.Event at 0758A050: GDK_CONFIGURE x=1946, y=348, width=199, height=173>)
2015-02-19 12:43:40,443 GLClientWindow(17 : gtk2.GLWindowBacking(17, (199, 173), None)).do_map_event(<gtk.gdk.Event at 0758A050: GDK_MAP>) OR=True
2015-02-19 12:43:40,443 GL do_configure_event(<gtk.gdk.Event at 0758A050: GDK_CONFIGURE x=1946, y=348, width=199, height=173>)
2015-02-19 12:43:40,520 do_motion_notify_event(<gtk.gdk.Event at 0758A050: GDK_MOTION_NOTIFY x=135.00, y=7.00>) wid=17 / focus=5, pointer=(2081, 355), modifiers=['mod2'], buttons=[1]
2015-02-19 12:43:40,614 _button_action(1, <gtk.gdk.Event at 076BFF50: GDK_BUTTON_RELEASE x=135.00, y=7.00, button=1>, False) wid=17 / focus=5, pointer=(2081, 355), modifiers=['mod2'], buttons=[1]
2015-02-19 12:43:40,614 button action: simulating a missing mouse-down event for window 5 before sending the mouse-up event
2015-02-19 12:43:40,927 do_motion_notify_event(<gtk.gdk.Event at 076BFE30: GDK_MOTION_NOTIFY x=134.00, y=8.00>) wid=17 / focus=5, pointer=(2080, 356), modifiers=['mod2'], buttons=[]
2015-02-19 12:43:40,943 do_motion_notify_event(<gtk.gdk.Event at 076BFE30: GDK_MOTION_NOTIFY x=133.00, y=9.00>) wid=17 / focus=5, pointer=(2079, 357), modifiers=['mod2'], buttons=[]

@totaam
Copy link
Collaborator Author

totaam commented Feb 19, 2015

2015-02-19 22:31:40: afarr uploaded file ticket770_windows-v-fedora21_windows-mouse-focus_epiphany-click.txt (61.2 KiB)

click on drop menu in epiphany, drop menu non-selectable

@totaam
Copy link
Collaborator Author

totaam commented Feb 19, 2015

2015-02-19 22:32:22: afarr uploaded file ticket770_windows-v-fedora21_windows-mouse-focus2_firefox-click.txt (60.9 KiB)

click on drop menu in firefox, try to select with a second click, non-responsive

@totaam
Copy link
Collaborator Author

totaam commented Feb 19, 2015

2015-02-19 22:33:02: afarr uploaded file ticket770_windows-v-fedora21_windows-mouse-focus3_firefox-hold.txt (51.5 KiB)

click and hold on drop menu in firefox, select by un-click, drop menu works as expected

@totaam
Copy link
Collaborator Author

totaam commented Feb 19, 2015

2015-02-19 22:34:57: afarr uploaded file ticket770_osx_mouse-windows-focus_epiphany-hold.txt (147.9 KiB)

osx client click-hold epiphany, drop menu non-interactive

@totaam
Copy link
Collaborator Author

totaam commented Feb 19, 2015

2015-02-19 22:36:37: afarr uploaded file ticket770_osx_mouse-windows-focus_firefox-hold.txt (19.7 KiB)

osx client click-hold firefox, drop menu behaves as expected

@totaam
Copy link
Collaborator Author

totaam commented Feb 19, 2015

2015-02-19 22:39:03: afarr commented

  • Quick last note, was testing on locate.apple.com .. one click on the "service" tile, then trying to click-release or click-hold on the "select a product" drop menu, then quit session... details to hopefully make logs more interpretable.

@totaam
Copy link
Collaborator Author

totaam commented Feb 20, 2015

2015-02-20 02:29:52: afarr commented

Testing again with windows client 0.14.20 8634 (your beta) against fedora 20 0.14.20 8645 (also your beta) ... I find the behavior (both firefox and epiphany) to be the same as the 0.15.0 trunk builds tested above.

@totaam
Copy link
Collaborator Author

totaam commented Feb 21, 2015

2015-02-21 15:17:59: antoine commented

(..) Apparently we had some trunk code in our 14.19 server/clients?)
Testing again with windows client 0.14.20 8634 (your beta) against fedora 20 0.14.20 8645 (also your beta) ... I find the behavior (both firefox and epiphany) to be the same as the 0.15.0 trunk builds tested above.
[[BR]]
This change has been backported to the v0.14.x branch (but not released yet), see comment:7.
I hope we can find a way of fixing this problem without reverting it...

Can you please clarify the difference between the two firefox: click + release + move vs click + hold + move?

I'm trying to find a simple example to test against with epiphany.
But for example: w3schools' tryhtml_option_selected works fine here.
I've also tried the steps from comment:11 (apple's site), still no luck!

@totaam
Copy link
Collaborator Author

totaam commented Feb 23, 2015

2015-02-23 21:47:41: afarr commented

Uhhmmm... testing again (to find a simple example with epiphany)... I can't repro the problem anymore - neither with epiphany nor with firefox... neither on the locate.apple.com nor on facebook.com sign in drop downs. Very odd.

Win32 client 0.15.0 r8689 (windows 8.1)
Fedora 20 server 0.15.0 r8661 (same as before).

Just in case, though, I'll try to clarify my made-up nomenclature. When clicking on a drop down, one can either simply click, or one can click and hold the button depressed.

For a time I was finding that, with firefox, if I just left clicked a drop down then moved the cursor over a selection and tried to left click to select - it was failing to select (click + release + move).

Meanwhile, if I left clicked but held the button depressed, then moved the cursor to a selection and un-clicked to select - it succeeded at selecting (click + hold + move).

With the new windows client though, either method is working as expected with either epiphany or firefox. (Could the fixes for the unicode errors mentioned in #786, or the SHGetPropertyStoreForWindow issues suspected related to #799 have "accidentally" fixed this issue?)

@totaam
Copy link
Collaborator Author

totaam commented Feb 24, 2015

2015-02-24 00:55:07: antoine commented

Just in case, though, I'll try to clarify my made-up nomenclature. When clicking on a drop down, one can either simply click, or one can click and hold the button depressed.
[[BR]]
OK, I thought that was how it worked (the description was adequate) but since I was having problems reproducing it, I was trying to make sure I wasn't just doing it wrong!

[[BR]]

With the new windows client though, either method is working as expected with either epiphany or firefox. (Could the fixes for the unicode errors mentioned in #786, or the SHGetPropertyStoreForWindow issues suspected related to #799 have "accidentally" fixed this issue?)
[[BR]]
I doubt it, but since this change is potentially disruptive, I am going to keep this ticket open and delay 0.14.20 until we've had a chance to test this some more.
How did Calvin originally reproduce the problem to be able to narrow it down to this changeset? (maybe re-assign to him?)

@totaam
Copy link
Collaborator Author

totaam commented Feb 27, 2015

2015-02-27 16:12:51: antoine commented

Any move on this?
Can you ask Calvin how he identified this changeset as problematic?

@totaam
Copy link
Collaborator Author

totaam commented Mar 3, 2015

2015-03-03 02:20:19: antoine commented

r8737 (+backport in 8738) allows us to toggle the implementation using the env var:

XPRA_REPARENT_ROOT=0 xpra start ...

I think this is safer as it gives us a way to go back to the previous behaviour if we have to.

@totaam
Copy link
Collaborator Author

totaam commented Mar 4, 2015

2015-03-04 01:08:58: afarr commented

Firstly, to answer the how/why of Calvin's identification and change... it was the latest changeset and largely a guess that, since the drop menus had been working before, they would (maybe?) work again if that change were reverted.

As to what I'm seeing investigating some more... it looks like the bugs I had been seeing in the drop down menu windows is now confined to OSX clients. On the other hand, while the XPRA_REPARENT_ROOT=0 environment variable seems to work for OSX, it horrendously breaks the win32 clients (at least, it does so with firefox & epiphany).

  • Testing with fedora 20 server 0.15.0 r8706 and r8743 against OSX 10.9 clients 0.14.20 r8743, 0.15.0 8647, and 0.15.0 r8743 ... I find that firefox behavior is as mentioned in comment:11.

(locate.apple.com - clicking and holding the drop down to select an item from either the sales or the service button item select drop menus, followed by releasing the click to select works as expected - but clicking & releasing, then trying to click again on a selection from the drop down menu displayed not only fails to select anything from the drop down menu, but seems to also be interpreted as a "held click", highlighting anything subsequently moused over.)

(Similarly, starting a gedit application and trying to use the application menu to select Search, then trying to select Replace from the displayed drop down menu fails ... though it fails the same whether the click is held and un-clicked to select or if it is released and a second click is attempted to make a selection from the menu.)

  • All of the above (both firefox and gedit) work as expected with the same server sessions and a win32 0.15.0 8709 or r8743 client.

  • Testing the r8743 0.15.0 OSX client against the fedora 20 server, with XPRA_REPARENT_ROOT=0 on the server side... all of the above work as expected.

  • Testing the fedora 20 0.15.0 r8743 server with XPRA_REPARENT_ROOT=0 (same session) against the windows 0.15.0 r8743 client, however ... the gedit drop menus behave as expected, but with firefox or epiphany, on the locate.spple.com page, I can only successfully click on the two left-most tiles & their associated drop menus... when I try to click on the two right-most (Service and Consulting), the clicks register on the left most tiles (Sales and Training) also... enabling a click on one of the "right-most" tiles to put keyboard focus in a textbox on a left-most tile (though, interestingly, not allowing the clicking on a drop down menu... or at least not thereby resulting in the display of a drop menu.

@totaam
Copy link
Collaborator Author

totaam commented Mar 5, 2015

2015-03-05 04:47:35: totaam commented

.. while the XPRA_REPARENT_ROOT=0 environment variable seems to work for OSX, it horrendously breaks the win32 clients (at least, it does so with firefox & epiphany).
[[BR]]
I don't understand this.
Setting this environment variable only effectively reverts the changeset and goes back to the pre r8484 behaviour. Please clarify and confirm that setting the env var to 0 gives the same behaviour as in 0.14.x.
If it does not, then we are dealing with something else - possibly related.

@totaam
Copy link
Collaborator Author

totaam commented Mar 6, 2015

2015-03-06 01:50:09: afarr commented

Well, nevermind - it looks like the issue with our win32 build (last issue with #799) tripped me up for this testing... with the fixed window client the XPRA_REPARENT_ROOT=0 environment variable is working as expected.

Passing it back.

@totaam
Copy link
Collaborator Author

totaam commented Mar 8, 2015

2015-03-08 17:04:31: antoine commented

Until I can investigate with OSX (virtualbox is having problems), I have changed the default value of XPRA_REPARENT_ROOT in r8763 for trunk and 8764 for v0.14.x

So we have to use "1" to enable reparent to root. (the default behaviour is now as it was before this change)

@totaam
Copy link
Collaborator Author

totaam commented Mar 9, 2015

2015-03-09 11:05:26: antoine commented

As far as I can tell, the [http://locate.apple.com/] widgets are just regular select HTML elements.

This is a much better and simpler test case for the drop down (with source visible): w3schools: try select form

[[BR]]

when I try to click on the two right-most (Service and Consulting), the clicks register on the left most tiles (Sales and Training) also... enabling a click on one of the "right-most" tiles to put keyboard focus in a textbox on a left-most tile..
[[BR]]
If I understand this correctly, this looks like a completely different issue. Sounds like the dummy driver is not patched. Please confirm that this is related to the reparent code, and if not create a new ticket for this issue.

@totaam
Copy link
Collaborator Author

totaam commented Mar 9, 2015

2015-03-09 11:09:25: antoine commented

In fact, we have a minimal test program already named "test drop down", just for this purpose - 37 lines all included . A million times better than testing with a browser.

Could well be related to #469. See also #713.

@totaam
Copy link
Collaborator Author

totaam commented Oct 18, 2015

2015-10-18 14:11:26: antoine commented

If this is still an issue, please provide simple reproduction steps (ie: preferably not using a browser)

@totaam
Copy link
Collaborator Author

totaam commented Oct 24, 2015

2015-10-24 02:13:13: afarr commented

Well, I can't seem to reproduce this with a browser anymore - so rather than trying to reproduce on something more simple, I'm going to conclude that it is no longer a problem.

Closing.

@totaam
Copy link
Collaborator Author

totaam commented Oct 24, 2015

2015-10-24 04:03:07: antoine commented

Re-opening as I need to make absolutely certain.

Did you test both with a server started with: XPRA_REPARENT_ROOT=1 ?
The default got changed back in comment:21.
Also please make sure you test with an osx client post r10983 as this bug would prevent some metadata from applying, potentially interfering with the testing.

@totaam
Copy link
Collaborator Author

totaam commented Oct 26, 2015

2015-10-26 23:29:26: afarr commented

Thanks for that heads up.

Tested again with XPRA_REPARENT_ROOT=1

0.16.0 r10972 fedora 21 server, 0.16.0 r11015 osx client, 0.16.0 r10983 windows client (on 8.1).

  • Drag and drop is working as expected.
  • Drop menus (both click and scroll and click again, and click-hold scroll & un-click) working as expected. (Firefox seems to have some issues with clipboard after copying an image, but that's not drag/drop related, so I'll make a ticket for it elsewhere.)

Can't find any sign of the issues in this ticket - closing again.

@totaam
Copy link
Collaborator Author

totaam commented Oct 27, 2015

2015-10-27 02:55:08: antoine commented

r11032 makes XPRA_REPARENT_ROOT=1 the default.

FYI: there is already a ticket for firefox clipboard weirdness which may be relevant: #883

@totaam
Copy link
Collaborator Author

totaam commented Nov 19, 2015

2015-11-19 13:23:26: antoine commented

This causes regressions like #911#comment:3, so this is reverted in r11292.

We'll also need to make sure we don't cause regressions with #814.

@totaam
Copy link
Collaborator Author

totaam commented Nov 19, 2015

2015-11-19 13:24:04: antoine commented

too late to deal with this, re-scheduling

@totaam
Copy link
Collaborator Author

totaam commented Sep 13, 2016

2016-09-13 16:34:00: antoine commented

Following some focus fixes in r13600, r13690 re-enables "reparent to root" again... hopefully we'll have better luck this time. Seems to work so far.

Note: this may cause regressions when connecting a new client to an old server and vice versa. (we can re-add some conditional workarounds via capabilities later on - just make a note of them for now but this is not the priority for testing, new to new is)

Tickets to (re)check: #814, #469, #911

@totaam
Copy link
Collaborator Author

totaam commented Sep 17, 2016

2016-09-17 02:48:00: afarr commented

Ok... testing with 1.0 r13763 osx client (10.9) against 1.0 r13767 fedora 23 vm.

Tried all the old-timey permutations I could think of with the locate.apple.com and the w3-schools link you provided, with both chrome and especially firefox (epiphany?, meh... don't care so much anymore)... both with a mouse and a tracpad. All looks well & good.

Tested the above with the default, which should be enabling "reparent to root" (and in the case of the issues mentioned in this ticket, also with XPRA_REPARENT_ROOT=1, which disables it again?... or maybe it should be tested with =0 and compared?).

In any case, it looks like you've successfully implemented "reparent to root" without breaking anything newly, though it would've been nice if it had fixed the "click-through" behavior of #469 as well.

Handing this back to you... I think I tested all the things that you were looking for and you can close this (though not #469), but let me know if I overlooked something.

@totaam
Copy link
Collaborator Author

totaam commented Sep 17, 2016

2016-09-17 06:38:39: antoine commented

Thanks!

I believe r13600 caused at least one bad regression reported in #1307 (server crash), now fixed in r13769. (you needed to disconnect lots of times to hit it - and maybe running something like gtkperf at the same time helps to hit that codepath)

Closing as we can follow up in #469 and I don't think we will need version specific toggles. (will just need to remember to re-test with older clients / servers before the final release)

@totaam
Copy link
Collaborator Author

totaam commented Mar 2, 2017

2017-03-02 12:01:02: antoine commented

This feature has caused another regression: gedit running on centos 6 with osx client... (see #1453#comment:1), and so the default has been reverted again in the v1.0.x branch.

I am hoping that we can fix this client-side and re-enable drag-n-drop in v1.0.x.
It's likely to be caused by focus / window id being reported wrong by the macosx client.

@totaam
Copy link
Collaborator Author

totaam commented Mar 10, 2017 •
edited
Loading

See #1453 comment:2, will follow up in #469 (re-opened).

@totaam totaam closed this as completed Mar 10, 2017
@totaam
Copy link
Collaborator Author

totaam commented Apr 10, 2017 •
edited
Loading

Follow up in #1493 for proper drag-n-drop support.

@totaam
Copy link
Collaborator Author

totaam commented Oct 30, 2018 •
edited
Loading

And another regression: #1999

This was referenced Jan 22, 2021
Closed
Closed
Closed
Closed
Closed
Closed
Closed
Closed
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@totaam