Editor windows enter a read only state on screen locks and workspace changes

[Adrian Wilkins]

Binary package hint: eclipse

Under certain circumstances, Java editor windows are locked to read-only. You can still navigate the text with the cursor, but the title of the tab is greyed out, and typing text into the window is locked. Sometimes this state is soluble by closing all current editor tabs, sometimes it requires a restart of Eclipse

Previously (in GNOME 2), this state only seemed to occur as the result of a screen lock (in GNOME), and even then, not reliably. I cannot seem to provoke this from a manual screen lock, so perhaps it only occurs when the screensaver kicks in.

In Unity, this seems to occur when you use desktop workspace switching to move to another desktop, and then back to the current one. This makes it much more annoying.

[Matthias Schmidt (mschmidt)]

I can confirm this behavior in Natty with Eclipse. The windows is read-only and you cannot work any longer. I have no screensaver working, so it seems its related to something else (probably window switching).

[Adrian Wilkins (adrian-wilkins)]

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...

[Marco Hunsicker (ubuntu-triemax)]

Same problem here. I use Natty with 9 virtual workspaces. Eclipse is opened in the center. Whenever I use Strg+Alt+Cursor to switch from another workspace to the Eclipse one, and Eclipse gets the focus, the editors are locked. I have to first switch to another application opened in the Eclipse workspace and back again to unlock the editors. Very annoying!

[Marco Hunsicker (ubuntu-triemax)]

The weird thing is that switching through the unity launcher works just fine, it's just not something I'm keen to do on a regular basis as it involves the mouse.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.