430650 - '^' and '¨' chars don't work in password fields

Status: RESOLVED FIXED

(Core :: Widget: Gtk, defect)

Description

[Tangui LE PENSE]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9b5) Gecko/2008041514 Firefox/3.0b5
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9b5) Gecko/2008041514 Firefox/3.0b5

My password contains a ^.
With Firefox3, when I fill my password in a password field (<input type="password"/>), nothing happends when I press the ^ key.
I use a French azerty keyboard.
With the other gnome apps, I have to press this key twice (usual behavior).
It also doesn't work with the '¨' key.

Reproducible: Always

Steps to Reproduce:
1. focus in a password field in a webpage
2. press the '^' key on a french keyboard
Actual Results:  
Nothing happens

Expected Results:  
A black circle should appear

Comment 1

[Justin Dolske [:Dolske]]

WFM on en-US ubuntu with a nightly, but if this is a problem it's almost certainly due to the locale keyboard. Can anyone else confirm this bug?

Preemptively requesting blocking, since if this is a reproducible problem it seems very bad to ship with.

Tangui: did this work in Firefox 2, or previous Firefox 3 betas?

Comment 2

[Carsten Book [:Tomcat]]

confirmed on Build identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008042404 Minefield/3.0pre, i see the same problem with the reporter on CentOS 5.

Works in Mozilla/5.0 (X11; U; Linux i686; de; rv:1.8.1.14) Gecko/2008040414 Firefox/2.0.0.14

Will try to find a regression range later.

Comment 3

[Tangui LE PENSE]

Justin : I never saw this problem before (I have been using Firefox since the beginning). I can test with other betas if you want.
Note that after pressing this key, the field keeps the focus.

Comment 4

[Damon Sicore (:damons)]

****.  +'ing this as I think this is a very serious blocker, and it appears that it's real.

Comment 5

[Sylvain Pasche]

That regression is there since a long time.

2006-07-03-04-trunk nightly has the issue, I didn't look more in the past.

Comment 6

[Carsten Book [:Tomcat]]

> That regression is there since a long time.
> 
> 2006-07-03-04-trunk nightly has the issue, I didn't look more in the past.
> 

confirmed, we shipped also alpha1 (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/2006120408 GranParadiso/3.0a1) with this regression. (In reply to comment #5)

Comment 7

[Damon Sicore (:damons)]

Assigning to Stuart since he has one less blocker than vlad.  ;-)

Stuart, please find the right person to fix this if it isn't you.  

Comment 8

[Sylvain Pasche]

Attachment: patch

I had a look at the issue, here are some explanations:

If you want to output a "¨" character on some keyboards, you have to type the key labeled "¨" twice. When you hit that key, the GDK_dead_diaeresis keysym is generated from GDK but it doesn't map to a unicode character in  nsConvertCharCodeToUnicode(). GTK uses the input module to send the IME event corresponding to the "¨" character when you type that key twice. However, the input module is disabled on passwords fields, because IsIMEEnabledState() in nsWindow.cpp does not enable it if the state is IME_STATUS_PASSWORD.

That patch enables IME for that state too. I'm not familiar with complex input modules, if doing this could be bad in some cases.

Comment 9

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I designed we cannot use im module on password field. The behavior is same on other native application's password field too, right? If so, this should be marked to INVA. If you need to enable im module at password field on your system, you can add following style in your user stylesheet.

input[type="password"] {
  ime-mode: normal;
}

Comment 10

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Comment on attachment 317832 [details] [diff] [review]
patch

This patch breaks very many features.

Comment 11

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

If you can use the dead keys on the native application's password file, we need new trick in IMEFilterEvent.

Comment 12

[Sylvain Pasche]

Dead keys are enabled on native GTK passwords fields. The entry.c example in the gtk+/examples/entry directory of the GTK sources can be useful for testing.

Comment 13

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Sylvain:

Thanks. I'll attach a draft patch.

Comment 14

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Oh, I forgot an important issue. SCIM doesn't process the key events via gtk_im_context_filter_keypress. Because gtk_im_context_filter_keypress doesn't send some important key combination to SCIM. Therefore, that hooks the key events directly during the IM context having focus. So, we cannot enable IME at password field. (Even if we don't call gtk_im_context_filter_keypress at that time.)

I need to think another approach...

# Can we process the dead keys ourselves??

Comment 15

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: The failed approach.

Comment 16

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: using simple context approach

This is using simple im context on password field. I'm not sure this works fine. Because I cannot test dead keys on my system.

Comment 17

[Sylvain Pasche]

I tested that patch and the dead keys are working fine on passwords fields.

If you want to test dead keys, maybe you can switch temporarily the keymap with setxkbmap. Type "setxkbmap de" to switch to the German layout, and then try the key labeled "^" on the top left of the keyboard visible at http://en.wikipedia.org/wiki/Keyboard_layout#Germany_and_Austria_.28but_not_Switzerland.29. Then you can get back to your original layout with "setxkbmap your_layout_code" (you have better know your layout code beforehand to avoid being stuck). Or you could use the gnome-keyboard-properties front-end under gnome.

Comment 18

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Patch v1.0

Thank you, I confirmed on my system too. Let's use this approach.

Comment 19

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Comment on attachment 317954 [details] [diff] [review]
Patch v1.0

Katakai-san, please hurry up to review this, if you can.

Roc: Would you r+sr for this? Even if we cannot get r+ from Katakai-san, we land this ASAP.

Comment 20

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 317954 [details] [diff] [review]
Patch v1.0

+    if (aState == mIMEData->mEnabled) {
         mIMEData->mEnabled = aState;

You can delete the second line now.

Comment 21

[Ralf Vitasek]

i seem to have a very similar (if not the same) issue with the '@' char in password fields.

on Mac OSX 10.5.2 i need to type the @ somewhere else and copy/paste it into the password field.

is this the same or should i file it as a new bug?

Comment 22

[Sylvain Pasche]

That should be bug 424524

Comment 23

[Masaki Katakai]

Comment on attachment 317954 [details] [diff] [review]
Patch v1.0

looks OK for me.

Comment 24

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Patch v1.1

Thank you, Roc and Katakai-san.

Comment 25

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 318391 [details] [diff] [review]
Patch v1.1

a1.9=beltzner

Comment 26

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

checked-in.