Closed Bug 430650 Opened 14 years ago Closed 14 years ago

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


(Core :: Widget: Gtk, defect)

Not set





(Reporter: tangui.lepense, Assigned: masayuki)


(Keywords: regression)


(1 file, 4 obsolete files)

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
Component: Form Manager → Password Manager
QA Contact: form.manager → password.manager
Component: Password Manager → Widget: Gtk
Product: Firefox → Core
QA Contact: password.manager → gtk
Version: unspecified → Trunk
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?
Severity: minor → major
Flags: blocking1.9?
Keywords: qawanted
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: Gecko/2008040414 Firefox/

Will try to find a regression range later.
Ever confirmed: true
Keywords: regression
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.
****.  +'ing this as I think this is a very serious blocker, and it appears that it's real.
Flags: blocking1.9? → blocking1.9+
Flags: in-litmus?
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.
> 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)
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.  
Assignee: nobody → pavlov
Attached patch patch (obsolete) — Splinter Review
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.
Keywords: qawanted
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 on attachment 317832 [details] [diff] [review]

This patch breaks very many features.
Attachment #317832 - Flags: review-
If you can use the dead keys on the native application's password file, we need new trick in IMEFilterEvent.
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.

Thanks. I'll attach a draft patch.
Assignee: pavlov → masayuki
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??
Attached patch The failed approach. (obsolete) — Splinter Review
Attachment #317898 - Flags: review-
Attached patch using simple context approach (obsolete) — Splinter Review
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.
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 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.
Attached patch Patch v1.0 (obsolete) — Splinter Review
Thank you, I confirmed on my system too. Let's use this approach.
Attachment #317832 - Attachment is obsolete: true
Attachment #317898 - Attachment is obsolete: true
Attachment #317904 - Attachment is obsolete: true
Attachment #317954 - Flags: review?(masaki.katakai)
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.
Attachment #317954 - Flags: superreview?(roc)
Attachment #317954 - Flags: review?(roc)
Comment on attachment 317954 [details] [diff] [review]
Patch v1.0

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

You can delete the second line now.
Attachment #317954 - Flags: superreview?(roc)
Attachment #317954 - Flags: superreview+
Attachment #317954 - Flags: review?(roc)
Attachment #317954 - Flags: review+
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?
That should be bug 424524
Comment on attachment 317954 [details] [diff] [review]
Patch v1.0

looks OK for me.
Attachment #317954 - Flags: review?(masaki.katakai) → review+
Attached patch Patch v1.1Splinter Review
Thank you, Roc and Katakai-san.
Attachment #317954 - Attachment is obsolete: true
Attachment #318391 - Flags: superreview+
Attachment #318391 - Flags: review+
Attachment #318391 - Flags: approval1.9?
Comment on attachment 318391 [details] [diff] [review]
Patch v1.1

Attachment #318391 - Flags: approval1.9? → approval1.9+
Closed: 14 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9
You need to log in before you can comment on or make changes to this bug.