Ubuntu
gnome-screensaver package

Unable to use XIM when screen is locked (xscreensaver)

Bug #183213 reported by Accord Tsai on 2008-01-15

Affects		Status	Importance	Assigned to	Milestone
	gnome-screensaver (Ubuntu)	Incomplete	Low	Basilio Kublik

Bug Description

Binary package hint: xscreensaver

Issue: XIM cannot be used normally under locked screen

Description: Users of languages other than English need an input method to input characters (e.g. Chinese). Seeing the window of the input method is necessary to choosing the correct character. When the screen is locked and using the "Leave message" function, the input method is activated but its window hidden, which makes choosing the characters impossible.

Desired result: When using "Leave message" under a locked screen, the window of the input method can still be seen (rather than hidden in the background as all the other processes)

Revision history for this message

Basilio Kublik (sourcercito) wrote on 2008-03-27:

Hi there
Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering is this still an issue for you? Can you try with the development version of Ubuntu, Hardy Heron?

Thanks in advance.

Changed in gnome-screensaver:
assignee:	nobody → sourcercito
importance:	Undecided → Low
status:	New → Incomplete

Revision history for this message

Accord Tsai (accordtsai) wrote on 2008-03-27:

Yes, under Ubuntu 7.10 this behavior is still present. I will test Hardy and report back when I have the chance. Thanks for your attention!

Revision history for this message

Accord Tsai (accordtsai) wrote on 2008-03-27:

Under Hardy Heron Beta the situation is still the same.

I tested with two different XIM engines, gcin and scim-chewing. Both of them were able to input Chinese characters in gedit. However, they are somewhat different. When typing in gcin, a floating window (though without borders) created near the caret displays the entered text, and allowing us to choose the characters. Hitting enter sends out the whole buffer to the application. When using scim-chewing with gedit, text was not shown in a separate window, but in the editing area, with recently entered characters underlined. Hitting enter sends out the buffer and removes the underline.

Ctrl + Space is the default hotkey for switching Chinese input on and off.

When using gcin: When typing in the "Leave message" text area, English characters are fine. Ctrl + Space switches on the Chinese input, though we are unable to tell. Keystrokes are sent to gcin (supposedly displayed in an unseen window) and nothing is added to the textarea. Upon hitting enter and sending out the buffer, the Chinese text appears in the text area. However, users do not get the chance to choose the characters.

When using scim-chewing: In the "Leave message" text area, I was unable to switch to Chinese mode. Hitting "a" produces "a", Ctrl + Space has no effect, and hitting "a" again enters "a" into the text area. I was only able to enter English characters.

Revision history for this message

Sebastien Bacher (seb128) wrote on 2009-05-14:

could you try if that's still an issue in jaunty?

Revision history for this message

Accord Tsai (accordtsai) wrote on 2009-05-19:

Yes, the same behaviour can be observed in jaunty.

Revision history for this message

Emmet Hikory (persia) wrote on 2009-09-18:

I'm unsure if this is also the case with XIM, but when using SCIM this bug is caused because SCIM discards synthetic XEvents (scim/extras/gtk2_immodule/gtkimcontextscim.cpp:981), and gnome-screensaver uses XEmbed to display the password and message dialogs, passing received XEvents with XSendEvent(). A similar issue was discovered using chromium with scim (http://code.google.com/p/chromium/issues/detail?id=19926), for which a patch to scim was developed. I'm also unsure if that patch is appropriate generally (consider the many cases where XSendEvent() could be used to compromise system security if it was accepted by the IME), or if a similar approach would address the issue for XIM.

If someone more familiar with XIM could confirm that this applies in that case, or if those experiencing the bug are willing to switch from XIM to SCIM, it may be appropriate to change the affected package for this bug to one of gtk+2.0 (the provider of the XIM GTK IMMODULE), scim (if use of SCIM rather than XIM is an acceptable resolution of this issue), or some other XIM related package (I'm not sufficiently familiar with XIM to be sure where such code may exist).