Input ignored when switching workspaces, closing windows...

[Micah Cowan]

Binary package hint: gnome-terminal

Steps to reproduce (some steps may not be necessary; I'm not on my home machine right now so can't eliminate the unnecessary steps):

  1. Open gnome-terminal
  2. Type some stuff (may not be necessary)
  3. Open a new tab via Control-Shift-T
  4. Type some stuff (may not be necessary)
  5. Close the tab (I usually do this via Control-D in the shell)

Resulting Behavior: Keys typed in the original tab are no longer processed (they are, however, queued up: see the Workarounds).

Expected Behavior: Keys typed in the original tab should be processed as normal, appearing and taking effect in the terminal.

Workarounds:
- Opening a new tab again will cause all the keys that had been typed in the original tab to be processed immediately. Closing that tab again results in the same buggy behavior. [NOTE: this does not appear to be the case lately; nothing previously typed is processed, it must be retyped.]
- Opening a new _window_, via Control-Shift-N, will cause all the keys to be processed immediately, and closing the new window does _not_ result in the original terminal window locking up again.

Apologies for not specifying the gnome-terminal package version; I'm away from the affected system at this moment. However, I am running Hardy Heron (8.04), and my packages were up-to-date as of last night.

[Pedro Villavicencio (pedro)]

thanks for your report, however isn't very clear, do you have any other easy steps in order to trigger the behavior? followed your steps and i get only a normal behavior here, thanks in advance.

[Micah Cowan (micahcowan)]

I thought it was quite clear: what is unclear about it? (Being unclear, and being unreproducible to you, strike me as distinct complaints.)

No other steps. The given steps reproduce the problem very reliably for me. Obviously there's a difference between my environment and yours, but as to what it might be, I couldn't guess.

Since gnome-terminal itself is actually responding to Control-Shift-T for opening new tabs, or Control-Shift-N for new windows, it seems entirely possible that the issue is really with libvte, or perhaps some issue involving both gnome-terminal and libvte. The fact that having opened a new tab or window alters the behavior, though, tells me that gnome-terminal must have at least something to do with it.

I've attached my profile settings, in case they are part of why I'm able to reproduce the problem. I'll try blowing it away, meanwhile, to see if that stops the issue.

Since I'm at my laptop, I now have the gnome-terminal version available: 2.22.1-0ubuntu2
libvte9 is 1:0.16.13-1ubuntu1.

[Micah Cowan (micahcowan)]

Okay, so I verified that, while blowing away my gnome-terminal config and restarting GNOME does not eliminate the problem, a fresh new account does not exhibit the symptoms.

The difference appears to be that my normal account is set up to use the SCIM X Input Method. On a fresh account, if I do an "im-switch -s scim", and then restart that user's GNOME session, I am then able to reproduce the symptoms on that account, using the steps I described. So, the issue is likely that gnome-terminal mishandles something related to XIMs (though, it _could_ be SCIM-specific).

People that use gnome-terminal and need to type in relatively exotic (usually, Asian) characters, will likely experience this problem, while folks who can get what they need from ASCII characters and maybe dead-letter keys or combination keys, probably won't.

[Micah Cowan (micahcowan)]

The problem isn't gnome-terminal: I've recently noticed that things like changing workspaces, or closing windows, can cause input not to be received in a window until I Alt-Tab twice to transfer focus away and back. This happens in a variety of applications, and so is not gnome-terminal specific. However, I'm unsure wherein the bug lies: could be SCIM, could be the wm (Metacity), could be X itself... Will try to find a better package to shift this to in the meantime.

[anoveth (gsjijon)]

I am also suffering from this problem.
It's exactly same symptom with the report of Micah.

[Pablo Castellano (pablocastellano)]

Confirmed as for last comment

[Micah Cowan (micahcowan)]

Still experiencing this on Intrepid. I hadn't been worrying about it because I wasn't using SCIM often enough to make it worth having enabled; however, I've been needing it again lately, and the symptoms are severe and annoying, to the point that the desktop is on the border-line of usable. Even switching from one window to another and back again leaves that window in a state where it does not accept input, and I must switch to another workspace and back again to (temporarily) resolve the issue.

[Arne Goetje (arnegoetje)]

when you do the switching, tab opening or closing, do you have scim enabled at that time (i.e. do you see the scim panel)? If yes, can you please close the scim panel (by pressing CTRL+Space) before you do the switching or tab opening / closing?

The reason is that all key presses get intercepted by SCIM when the scim panel is active. These key presses are associated with the current active window / tab where scim was activated. If you close the tab or switch the window before the keysym queue got cleared, you may experience the described behavior.

If the problem still persists, can you please attach your ~/.scim/config, /etc/scim/config and /etc/scim/global configuration files?

[Micah Cowan (micahcowan)]

Thanks for the swift response, Arne.

I managed to find the core report, which at least has some suggested workarounds. Switching from "scim" to "scim-immodule" seems to have fixed it for so far (for 30 seconds' worth of testing, anyhoo). Hopefully I don't need any libstdc++5 apps too soon.

[Arne Goetje (arnegoetje)]

Micah Cowan wrote:
> *** This bug is a duplicate of bug 66104 ***
> https://bugs.launchpad.net/bugs/66104
>
> ** This bug has been marked a duplicate of bug 66104
> [Gutsy] scim: input freezes in various applications under XIM mode
>

Does this mean the issue has been resolved for you?

[Micah Cowan (micahcowan)]

Arne, well, this issue report is now a duplicate, so I don't believe you can "resolve" this report.
This issue will be resolved when the core report is resolved; at this time, the problem still exists as of Intrepid, but an acceptable workaround is letting me get things done. The core report leads me to understand that it may be resolved in Jaunty (the issue is marked "Fix Released" for the various targeted projects); so I don't think there's anything further to do with this ticket (or the core ticket, provided that it really has been resolved in Jaunty).

Thanks for your help!

[grabaldam (grabaldam-deactivatedaccount)]

I am using Kubuntu Jaunty and the problem is still here.