Description of problem: While creating a new user or editing an existing one, one can not type the full name of the user in Unicode (using Ctrl+<space> to get the SCIM menu). However the same string can be copy-pasted from somewhere else (eg., GEdit). Version-Release number of selected component (if applicable): 1.2.42 How reproducible: Can be reproduced every time as follows: Steps to Reproduce: 1. Open system-config-users: # system-config-users 2. Double-click an existing user, or try to create a new one. 3. Try to type the user's full name in Unicode, using ctrl+<space> to get the SCIM menu. Actual results: Menu would not pop-up, although it is possible to copy paste from somewhere else, like GEdit Expected results: A SCIM menu ought to have popped out to allow the user to chose the language. Additional info: n.a.
GTK_IM_MODULE environment variable seems to be ignored - for testing, I did enable the IM context menu, and when s-c-users runs, current IM pointed to XIM. it works after changing it to scim from the IM context menu. I'm not sure why. consolehelper may drops the environment variables perhaps like sudo does in some case?
Reassigning to usermode then, this is nothing I can fix in s-c-users.
Matthias, can you please confirm that using an user-supplied, untrusted GTK_IM_MODULE value within a GTK+ application run by root is secure? Also, can any of the substrings "..", "/" and "%" legitimately appear in the value of GTK_IM_MODULE?
This issue is present in Rawhide (updated Fedora 7 test 4) as well.
with latest rawhide (after F8 release), problem continue... usermode-1.93.1-1.fc8
Matthias?
In reponse to comment #4: no, I cannot confirm that. Running GUI applications as root is really not the right approach, and the gtk team has been saying that for years. See PolicyKit for how to do this right.
(In reply to comment #4) > Also, can any of the substrings "..", "/" and "%" legitimately appear in the > value of GTK_IM_MODULE? Normally GTK_IM_MODULE is just the name of the gtk immodule: eg "scim" or "scim-bridge".
(In reply to comment #8) > In reponse to comment #4: no, I cannot confirm that. Thanks.