Closed Bug 1143197 Opened 10 years ago Closed 10 years ago

Unable to enter text in <input type=password> fields when an input method is available (Linux)

Categories

(Core :: Widget: Gtk, defect)

Product:
Core
Component:
Widget: Gtk
Version:
36 Branch
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla39
Tracking Flags:
Tracking Status
firefox39 --- fixed

People

(Reporter: mozilla3, Assigned: masayuki)

References

Details

(Keywords: regression, testcase)

Attachments

(4 files, 1 obsolete file)

Backout patch (for reference)
4.82 KB, patch
Details | Diff | Splinter Review
Simple testcase (updated)
52 bytes, text/html
Details
part.1 Use current IM context at handling key events rather than active IM context
11.40 KB, patch
m_kato
: review+
Details | Diff | Splinter Review
part.2 Assume that composition is committed if a call of gtk_im_context_reset() causes composition string becomes empty
2.24 KB, patch
m_kato
: review+
Details | Diff | Splinter Review
On Linux, when an input method program (tested with ATOK X3: http://www.justsystems.com/jp/products/atok_linux/) is running, Firefox 36 ignores all keyboard input in password input elements, even if the input method is not active. If the input method is active, preedit text is shown with all characters replaced by dots as expected, but upon confirming the preedit text, it is deleted rather than being entered into the field. Middle-clicking in the field (X11 paste) works correctly. The bug is reproducible with any password input element, for example: <html><body><form><input type=password></form></body></html> This is a regression from Firefox 35. hg bisect identified r214831:081b41591d86 as the culprit, and backing it out on top of FIREFOX_AURORA_36_BASE appears to fix the problem, though I don't know whether that might break anything else. The default branch (as of r233609:38154607d807) has the same issue, and the same fix applies. To reproduce: 1. Start an input method program. 2. Start Firefox. 3. Confirm that Firefox recognizes the input method (for example, by activating it, typing into the URL bar, and seeing that the keystrokes are properly processed by the input method). 4. Check that the input method is disabled, so that it does not process incoming keystrokes. 4. Open an HTML page containing an <input type=password> element. 5. Click in the password input box. 6. Press a key that would normally generate input (such as "a"). Expected behavior: A dot (hiding the entered character) is displayed in the password input box. Observed behavor: Nothing is displayed in the password input box.
> This is a regression from Firefox 35 I assume you meant Firefox 36. Rev. 081b41591d86 is bug 1083067 which is labelled as a change in 36.
Blocks: 1083067
Severity: normal → major
Component: Editor → Widget: Gtk
Flags: needinfo?(masayuki)
Keywords: regression, testcase
(In reply to Mats Palmgren (:mats) from comment #1) > > This is a regression from Firefox 35 > > I assume you meant Firefox 36. Rev. 081b41591d86 is bug 1083067 which > is labelled as a change in 36. I meant a regression _from_ Firefox 35 (which works correctly) _in_ Firefox 36 (which is broken). Sorry if that was unclear.
Some points are not clear to me. 1. You said that you use ATOK X3. IIRC, it uses IIIMF. Can you reproduce this bug with other IMs such as SCIM, iBus? 2. Do you reproduce this bug with another language engine such as FreeWnn (FYI: http://wiki.fdiary.net/iiimf/?c=src;p=Language+Engines)? 3. Which distribution are you using? If you customize the environment, please tell us the information too.
Flags: needinfo?(masayuki)
IIRC, piro-san, you used ATOK X3. If you keep using it, do you reproduce this bug?
Flags: needinfo?(yuki)
Attached file Simple testcase (obsolete) —
This is a simple testcase. With the CSS rule "ime-mode:disabled", I can reproduce this problem. Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Firefox/36.0 (not Ubuntu's binary, this is the official binary downloaded from mozilla.com)
Flags: needinfo?(yuki)
The previous testcase has needless attributes. This is very simple version only with "style" attribute.
Attachment #8577560 - Attachment is obsolete: true
Status: UNCONFIRMED → NEW
Ever confirmed: true
Thank you, Piro-san. I'll try to install ATOK X3 on my Ubuntu environment on Monday...
Additional info: my ATOK X3 was installed to Ubuntu 14.04LTS, with steps instructed at http://sicklylife.at-ninja.jp/memo/ubuntu1404/settings.html#atok_in
I guess that OnEndCompositionNative() doesn't run with ATOK X3. Therefore, we probably miss releasing active context. We need to reset it in somewhere.
(In reply to YUKI "Piro" Hiroshi from comment #8) > Additional info: my ATOK X3 was installed to Ubuntu 14.04LTS, with steps > instructed at > http://sicklylife.at-ninja.jp/memo/ubuntu1404/settings.html#atok_in Thank you! It's really helpful to me!!
> -1661675648[7f209bb38580]: GtkIMModule(7f208064b6c0): Init, mOwnerWindow=7f208cc31bb0 > -1661675648[7f209bb38580]: GtkIMModule(7f2077931880): Init, mOwnerWindow=7f2077937a10 > -1661675648[7f209bb38580]: GtkIMModule(7f2077931880): OnFocusWindow, aWindow=7f2077937a10, mLastFocusedWindow=0 > -1661675648[7f209bb38580]: GtkIMModule(7f2077931880): Focus, sLastFocusedModule=0 > -1661675648[7f209bb38580]: GtkIMModule(7f2077931880): OnStartCompositionNative, aContext=7f2085138670, current context=7f2085138670 > -1661675648[7f209bb38580]: GtkIMModule(7f2077931880): DispatchCompositionStart, aContext=7f2085138670 > -1661675648[7f209bb38580]: FAILED, cannot query the selection offset > -1661675648[7f209bb38580]: GtkIMModule(7f2077931880): OnChangeCompositionNative, aContext=7f2085138670 > -1661675648[7f209bb38580]: GtkIMModule(7f2077931880): GetCompositionString, result="" > -1661675648[7f209bb38580]: GtkIMModule(7f2077931880): SetInputContext, aCaller=7f2077937a10, aState=DISABLED mHTMLInputType= > -1661675648[7f209bb38580]: GtkIMModule(7f2077931880): EndIMEComposition, aCaller=7f2077937a10, mCompositionState=NotComposing > -1661675648[7f209bb38580]: GtkIMModule(7f2077931880): Blur, mIsIMFocused=YES > -1661675648[7f209bb38580]: GtkIMModule(7f2077931880): Focus, sLastFocusedModule=7f2077931880 > -1661675648[7f209bb38580]: GtkIMModule(7f2077931880): Blur, mIsIMFocused=YES > -1661675648[7f209bb38580]: GtkIMModule(7f2077931880): SetInputContext, aCaller=7f2077937a10, aState=DISABLED mHTMLInputType= > -1661675648[7f209bb38580]: GtkIMModule(7f2077931880): SetInputContext, aCaller=7f2077937a10, aState=DISABLED mHTMLInputType= > -1661675648[7f209bb38580]: GtkIMModule(7f2077931880): SetInputContext, aCaller=7f2077937a10, aState=DISABLED mHTMLInputType= > -1661675648[7f209bb38580]: GtkIMModule(7f2077931880): SetInputContext, aCaller=7f2077937a10, aState=DISABLED mHTMLInputType= > -1661675648[7f209bb38580]: GtkIMModule(7f2077931880): SetInputContext, aCaller=7f2077937a10, aState=DISABLED mHTMLInputType= > -1661675648[7f209bb38580]: GtkIMModule(7f2077931880): SetInputContext, aCaller=7f2077937a10, aState=DISABLED mHTMLInputType= > -1661675648[7f209bb38580]: GtkIMModule(7f2077931880): SetInputContext, aCaller=7f2077937a10, aState=PASSWORD mHTMLInputType=password > -1661675648[7f209bb38580]: GtkIMModule(7f2077931880): Focus, sLastFocusedModule=7f2077931880 > -1661675648[7f209bb38580]: GtkIMModule(7f2077931880): Blur, mIsIMFocused=YES > -1661675648[7f209bb38580]: GtkIMModule(7f2077931880): OnFocusChangeInGecko, aFocus=YES, mCompositionState=NotComposing, mIsIMFocused=NO > -1661675648[7f209bb38580]: GtkIMModule(7f2077931880): OnSelectionChange(aCaller=0x7f2077937a10), mCompositionState=NotComposing > -1661675648[7f209bb38580]: GtkIMModule(7f2077931880): ResetIME, mCompositionState=NotComposing, mIsIMFocused=NO > -1661675648[7f209bb38580]: GtkIMModule(7f2077931880): SetInputContext, aCaller=7f2077937a10, aState=PASSWORD mHTMLInputType=password Odd... ATOK X3 (or IIIMF) stats composition without composition string when our process starts. Then, DispatchCompositionStart() fails to dispatch compositionstart. After that, ATOK X3 never sends "preedit_end" signal to us...
Even if I commit composition explicitly (i.e., normaly with pressing Enter key), "preedit_end" signal never comes from ATOK X3 or IIIMF. This is too bad behavior. We need hack for this. On the other hand, I reailzed that key event handler shoudn't send key events to the active IM context because if the keyboard focus is changed to another IM context, the new IM context should receive the key events. I guess that without complicated hack, temporarily this bug could be hidden.
Assignee: nobody → masayuki
Status: NEW → ASSIGNED
Currently, we may use two IM contexts at a moment. One is "active" context which means that the IM context still needs to be handled requests/notifications to IME even after focus is moved to another IM context. The other is "current" context which is switched when focus is moved synchronously. When we handle key events, we should use current context rather than active context because remaining composition after a focus move shouldn't receive key events on the new IM context. FYI: some IME may cause "commit" signal for a character input by a key press. Therefore, we need to hack OnCommitCompositionNative() too. Therefore, it needs to check whether aContext has composition or not.
Attachment #8579273 - Flags: review?(m_kato)
Only with the part.1, ATOK cannot restart composition after committing composition by a mouse click. The reason is, ATOK X3 never sends "commit" signal at committing (canceling) composition when gtk_im_context_reset(). Therefore, nsGtkIMModule doesn't detect the composition was already committed at receving next "preedit_changed" signal. For solving this issue, we should check if nsGtkIMModule thinks there is composition but the composition string is empty after a call of gtk_im_context_reset(). In such case, we should emulate "commit" signal internally.
Attachment #8579275 - Flags: review?(m_kato)
Attachment #8579273 - Flags: review?(m_kato) → review+
Comment on attachment 8579275 [details] [diff] [review] part.2 Assume that composition is committed if a call of gtk_im_context_reset() causes composition string becomes empty Review of attachment 8579275 [details] [diff] [review]: ----------------------------------------------------------------- gtk_im_context_reset's behavior may be different of each IM framework (SCIM vs iBus vs IIIMF). If no regression of using other framework such as SCIM, it s is OK for this.
Attachment #8579275 - Flags: review?(m_kato) → review+
I haven't worked with GTK+ IM contexts so I can't speak to the technical merits of the patch, but I can confirm that in my environment, it fixes the problem I observed with password input elements and it doesn't seem to break Japanese input anywhere else. Thanks!
(In reply to Makoto Kato (:m_kato) from comment #15) > Comment on attachment 8579275 [details] [diff] [review] > part.2 Assume that composition is committed if a call of > gtk_im_context_reset() causes composition string becomes empty > > Review of attachment 8579275 [details] [diff] [review]: > ----------------------------------------------------------------- > > gtk_im_context_reset's behavior may be different of each IM framework (SCIM > vs iBus vs IIIMF). If no regression of using other framework such as SCIM, > it s is OK for this. Thanks, I already checked with iBus. I'll check also with SCIM and fcitx.
Is this backported to Firefox 38 (next ESR) or older versions?
(In reply to YUKI "Piro" Hiroshi from comment #20) > Is this backported to Firefox 38 (next ESR) or older versions? Um, I still not sure. The part.2 is risky for other IMEs. Especially for Chinese IMEs. So, we should wait some bug reports for some weeks.
(In reply to YUKI "Piro" Hiroshi from comment #20) > Is this backported to Firefox 38 (next ESR) or older versions? I have a question, do you have some trouble caused by this bug in your business? If so, I think that we should take it to ESR 38 for your clients at least.
Flags: needinfo?(yuki)
I'm using ATOK X3 on Ubuntu at my job-related PC, because it is painful for me to write well-quality technical documents - for example, reports for technical questions from my business clients - with Mozc, Anthy or something major open-source input methods. But it is just my private reason. I've never heard that my client uses ATOK on Linux.
Flags: needinfo?(yuki)
(In reply to YUKI "Piro" Hiroshi from comment #23) > I'm using ATOK X3 on Ubuntu at my job-related PC, because it is painful for > me to write well-quality technical documents - for example, reports for > technical questions from my business clients - with Mozc, Anthy or something > major open-source input methods. > > But it is just my private reason. I've never heard that my client uses ATOK > on Linux. Thank you for the quick reply. I asked whether the behavior is ATOK X3 specific or not unofficially. Then, the behavior is probably ATOK specific. And the behavior is very odd according to the GTK's spec. Additionally, ATOK X3's share isn't so big. Unfortunately, the change might cause some regressions with Chinese IMEs since some of them compose text with empty composition string. Therefore, for the risk management, we should wait feedback from Chinese testers enough time. Sorry for the inconvenience, but I'd like you to understand the reason why I don't request approvals soon.
Anyway I've verified that the Nightly 40.0a1 (Build ID: 20150330114816) works fine with the simple testcase I attached. Thanks a lot!
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: