GNOME Bugzilla – Bug 768972
Unable to type in a password field in Firefox when using certain GNOME Input Sources
Last modified: 2021-07-05 14:45:05 UTC
This is an oddly specific bug, but I can reproduce the bug 100% of the time under the described conditions: ## Context Syncthing <https://syncthing.net/> is an open source peer-to-peer folder sharing application. It is normally run from the command line or as a systemd service, but has a web UI for adding, removing, and configuring shared folders and other settings. The web interface can have an admin username and password set, so that you can administer the Syncthing service remotely. ## The problem I cannot edit the Syncthing web UI password in Firefox when I have enabled the GNOME Input Sources "Japanese (Kana Kanji)" or "Chinese (Intelligent Pinyin)." These are the input sources that let you type the Latin transliteration for the Japanese or Chinese words and then substitute Japanese/Chinese characters as you type. When I click the password field to type in a password, the GNOME top bar icon indicating which Input Source I'm using disappears for a split second, then reappears. And the Syncthing password field remains blank and unresponsive, un-editable. ## Steps to reproduce I'm testing this using GJS 1.45.3 and GNOME 3.20 on Fedora 24 (64-bit), with Syncthing 0.14.0, and Firefox 47.0.1. 1. From a Linux + GNOME desktop, download/install Syncthing, or get a static binary. Start it, and open the Syncthing web UI in Firefox. (Note: This issue does not exist when I tried visiting the web UI in Google Chrome, Opera, GNOME Web, or Midori. And other users who do not use GNOME have had no issue using Firefox.) 2. Go to GNOME Settings > Region & Language > Input Sources, and add either "Japanese (Kana Kanji)" or "Chinese (Intelligent Pinyin)". (Note: My native language is English; the problem persists whether or not I actually have Japanese or Chinese language input selected. But the problem disappears if the secondary language is something like German, or "Japanese (Dvorak)", which do not involve substituting characters as you type.) 3. Go the Syncthing web UI > Actions > Settings, and try to type in the field labeled "GUI Authentication Password." You won't be able to type in a password. (Note: Other text fields can be edited as normal, though.) ## Narrowing down the source of the problem. So there's some kind of weird interaction between Firefox, the GNOME Latin-to-East-Asian-language conversion features, and the Syncthing Settings password field. I'm not entirely sure where in that software stack the bug lies, though. The Firefox JavaScript console shows no errors or warnings when navigating to the Syncthing web UI, nor when clicking on the password or other text fields. And from a cursory glance, I don't see anything weird or wrong with the web UI's scripts or HTML. And non-GNOME Syncthing users were unable to reproduce the bug: <https://github.com/syncthing/syncthing/issues/3413> And I've used the GNOME language settings to let me more easily write Japanese for a long time, and I've never had a problem typing in password fields in Firefox before... So I don't think it's an issue with Firefox. GJS is used a lot in the GNOME 3 platform, and is based on Mozilla's JavaScript engine, Spidermonkey, which I thought might explain the peculiar interaction between Firefox and the GNOME language input sources. That's assuming that the GNOME Input Sources uses GJS, though, and I don't know what their software stack is like. Let me know if you need any more information, or if I should refile this bug report somewhere else.
Thanks for reporting this! The SpiderMonkey engine running inside Firefox is definitely a different process (different version of the engine, even) than the one running inside GJS, so I doubt GJS is the cause of this. I'm reassigning this to gnome-shell (because I think that's where input source bugs go, but I'm not sure) although I would give it about a 50% chance that the bug is in Firefox rather than gnome-shell.
I can also reproduce on the Loudr login page, which will probably be easier to test on, since you don't have to install Syncthing... Go to https://loudr.fm and click on "Sign In" in the top-right corner of the page. Try clicking on the password field -- the input sources icon in the GNOME Shell panel disappears and reappears, but the text cursor never shows up in the password field, so you can't type anything. Currently testing using Firefox 52.0, running on Fedora 25 Workstation x86_64 Linux, with GNOME Shell 3.22 in an Xorg session.
I'm guess this is limited to the X11 session? I could not reproduce this issue when running using the Wayland session. Firefox is still using X11, but I can enter a password. I have three input methods that I switch between (Swedish, English and libpinyin for Chinese), but only English and Swedish were available choices for the password field. But I guess that is to be expected.
Huh, not sure how I missed your response, Jonas, sorry. I've duplicated the issue in both Xorg and Wayland sessions, now running Firefox 54.0 on Fedora 26 Workstation x86_64 with GNOME Shell 3.24. I still can't type anything in the password field of the Loudr.fm login widget.
Still an issue with Firefox Developer Edition 60.0b4 in Fedora 27 Workstation, with GNOME Shell 3.26.2 in an Xorg session.
Still an issue on my system. * Firefox stable 61.0.2, and Firefox Developer Edition 62.0b17 * Fedora 28 Workstation x86_64 * GNOME Shell 3.28.3, in both Xorg and Wayland sessions * iBus 1.5.18 I've also started to notice this bug on my credit card company's website, <https://www.capitalone.com/>, so I can't login using Firefox while these text suggestion-and-conversion Input Sources are enabled, whether or not I'm actually *using* the alternate input methods at the time. I decided to report it to Mozilla too, for increased visibility, although I'm not really sure that it's a problem in Firefox... https://bugzilla.mozilla.org/show_bug.cgi?id=1484467
Fujiwara on the Mozilla Bugzilla referenced this related issue. https://gitlab.gnome.org/GNOME/gnome-shell/issues/391 I'm not sure I understand everything in Fujiawara's original post there on the GNOME GitLab, but the issue might be getting at the same underlying problem as my issue here.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/ Thank you for your understanding and your help.