Comment 2 for bug 781618

Revision history for this message
Adrian Wilkins (adrian-wilkins) wrote :

I think I've pinned this down now - it's to do with rdesktop, which I habitually use to integrate a Windows laptop into my main desktop setup. I also have a workaround.

To reproduce ;

 * Open an rdesktop connection to something
   * I'm using the -DKz options to remove the window border and keep the ability to use the workspace switching keys
   * Arrange the window so there is space to move the mouse pointer outside
 * Place the rdesktop session on a workspace other than the Eclipse instance
 * Open an Eclipse instance
 * Edit some Java code
 * Switch workspaces back to the rdesktop workspace
  * Focus is now with the rdesktop window
 * Click in the rdesktop window
 * Move the mouse pointer outside the window
 * Switch workspaces back to the Eclipse workspace
  * Focus shifts back to the Eclipse window
 * Click in the editor area and note that the tab is greyed out and edits are impossible
 * Any other tabs in the editor area for this window are also read-only now

Workaround : This only happens when the focus transitions from rdesktop to the original edit window, as the result of a workspace shift. It seems to be most reliable when the mouse is not within the rdesktop window when the workspace shift occurs, but you may have to fiddle a bit to get it to occur.

Other focus transitions reset this state ; so if you have, for example, a second Eclipse window open (this is a double-screen workspace), you can click in the editor area of this window and then back again, and the write lock is cleared.

(if you need an rdesktop server but don't have a copy of Windows, VirtualBox provides an rdesktop server so you can access virtual machines remotely).

So, I'm not entirely sure where the fix for this lies... having a workaround is nice, but it's taken me a while to work out what it is.

I'm guessing it's the responsibility of the window manager to transfer focus properly BUT I think some of the things that rdesktop does with focus are possibly a little hinky, maybe because it intercepts keystrokes. And perhaps something about the way the focus is returning to Eclipse is odd (event timing / ordering?) , but really, it should be the responsibility of Eclipse / JFace to work properly. So I'm just posting this here...