Closed Bug 1484467 Opened 6 years ago Closed 6 years ago

Unable to type in a password field in Firefox when certain iBus input methods are installed

Categories

(Core :: Widget: Gtk, defect)

62 Branch
Unspecified
Linux
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 1451466

People

(Reporter: audrey, Unassigned)

Details

(Keywords: inputmethod)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0
Build ID: 20180813190114

Steps to reproduce:

This is an oddly specific bug, but I can reproduce the buggy behavior 100% of the time under the described conditions...

GNOME Shell lets you add alternate "Input Sources" that lets you switch keyboard layouts or otherwise more easily type text in another language (Settings > Region & Language > Input Sources) via underlying iBus technology. Other Linux desktop environments can do the same by configuring iBus directly.

Some iBus input methods are more advanced than others, such as "Japanese (Kana Kanji)", which lets me type normal Latin letters in my keyboard's native US layout, and then when I hit Space, it shows a small pop-up menu at the cursor to convert the text to Japanese characters. Similarly, there's an input method called "Other (Typing Booster)" which lets you type Latin letters, and the pop-up menu shows suggestions for complete English words or emoji, such as the smiley face when you start to type "smile". Text conversion-and-suggestion methods like these seem to show little gear icons next to their name in the GNOME Input Sources selection menu, to show that they're more advanced than just switching keyboard layout.

I can't type in some website login password fields while any of these advanced input methods are enabled, whether or not I'm actually *using* an alternate input method when trying to select the password field: As long as the suggestion-and-conversion input methods have been *added* in the Input Sources settings, I can't select or write in a password field, even if I'm using my keyboard's native plain US layout. But there's no problem if the all other input methods enabled are normal, simple keyboard layouts, like Italian or German.

Not all websites are affected by this bug. For me, I run into this problem most often when attempting to login to <https://loudr.fm> or <https://www.capitalone.com> but I've seen it on a few other sites too. Only Firefox seems affected by this bug.

So there seems to be some weird interaction between Firefox, the Loudr and Capital One and other websites, and either the GNOME Shell Input Sources or iBus itself (I'm not terribly familiar with what this software stack). I reported this to the GNOME project first, but one commenter speculated it might be a bug in Firefox instead.

    https://bugzilla.gnome.org/show_bug.cgi?id=768972

Workarounds include temporarily removing the text-conversion Input Sources (a little tedious), or using Google Chrome to login to the affected websites instead (not ideal either).

My system setup:

* Firefox stable 61.0.2, and Firefox Developer Edition 62.0b17
* Fedora 28 Workstation x86_64
* GNOME Shell 3.28.3
* iBus 1.5.18


Actual results:

If you have added any of these advanced input methods, you can't type into the password field in the login page for certain websites. Whenever I try to click in the password field, the Input Sources status icon in the top bar of GNOME Shell disappears for a half second, then reappears, but the text cursor never shows in the password field and I can't type anything. Same thing happens if I select the password field using the Tab key instead.


Expected results:

Users should be able to type in the password field for any website using any input method.
Keywords: inputmethod
OS: Unspecified → Linux
Component: Untriaged → Widget: Gtk
Product: Firefox → Core
Ah, yes. I've been using GNOME in an Xorg session, I should have mentioned. After reenabling Wayland, I'm able to type in password fields on the sites I mentioned again.

Guess I'm not sure now if this is *just* a GNOME issue, then, or if the Firefox team could mitigate the issue on their side of things... I'll let you guys decide whether to close this ticket as an upstream problem or not.
I think there is nothing for firefox to fix the issue and suggest to close this issue.
Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.