GNOME Bugzilla – Bug 317002
Disable input method completely in GtkEntry when it's in invisible mode.
Last modified: 2008-09-29 23:57:01 UTC
GtkEntry is used by many other applications (like gdm) to input passwords. In such case, GtkEntry will be turned into invisible mode. All inputted content and preedit string will be hidden, thus most input methods will be very hard to use in such situation. And using characters other than ASCII chars in password is not so practical as well. In some situation (for example in gdm), if an input method is opened by accident when user is inputting password, the user will be very confused. So I think that the input method should be disabled completely in GtkEntry, if it's in invisible mode. A patch for gtk+ 2.8.3 will be attached to fix this issue.
Created attachment 52534 [details] [review] The patch against gtk+ 2.8.3 to fix this issue.
The bugzilla.novell.com entry for reference: https://bugzilla.novell.com/show_bug.cgi?id=117115
Created attachment 52796 [details] [review] A new patch with a different approach. This patch could avoid some incompatibility issue with some Java SWT apps of the old patch.
Is there any progress on this bug?
2005-11-18 Matthias Clasen <mclasen@redhat.com> Turn off input methods in invisible entries, since they are confusing. (#317002, James Su) * gtk/gtkentry.c (gtk_entry_set_visibility): Toggle input methods if visibility changes. (popup_targets_received): Don't show the input method menu if the entry is invisible.
this breaks password entries with multitap input method and with IM used to pop up an on-screen virtual keyboard, thus making it impossible to type passwords without a full keyboard. see bug 491759.
Continuing from Emmanuele's comment, what about situations where an input method other than "simple" is needed to enter *anything*, for example the multitap IM Murray wrote (where without the IM the only keys available are 0-9), or a virtual keyboard such as Matchbox Keyboard (where without the IM there is no keyboard at all). Yet alone the people who use one of the other IMs such as Thai, with this is it really impossible for them to enter passwords in Thai? I'd like to see this reverted, and any usability issues with using the standard IM in invisible mode resolved. I'm mainly wondering what is actually "confusing" about using the user's IM in a password field?
Oh, I should also point out that Maemo also disables this creation of a simple IM, and only uses the multicontext created in gtk_entry_init().
Hmm, maybe we need to refine our approach. Looking at the original suse patch, there are two problems here: a) password entries are used in situations where the usual feedback on im status (scim statusbar icon) is not visible: login screen, screensaver lock dialog. Therefore, the user has no easy way to see whats going on b) preedit text is replaced by stars, rendering IMs that rely on preedit hard to use, if at all Possible solutions: 1) implement the proposed capslock warning in bug 530568 and extend it to also warn about IMs 2) don't hide preedit text
Created attachment 119563 [details] [review] patch Here is a patch that does the following: 1) make preedit text visible even if the entry is invisible 2) don't force imcontextsimple in invisible mode 3) fix a problem with backspace in invisible mode
This patch was committed, and I also added a capslock/inputmethod warning for password entries.