discord.com - Text field is not ready to receive input after switching languages

[ishitatsuyuki]

URL: https://discord.com/app

Browser / Version: Firefox 84.0
Operating System: Linux
Tested Another Browser: Yes Chrome

Problem type: Something else
Description: Input controls loses focus when switching IBus IME mode
Steps to Reproduce:
A blur event seems to sent to the document/window when the tab loses focus. Discord seems to show some weird behavior, removing the focus from textbox if it (the window?) receives a blur event.
When using IBus with a Japanese IME on Linux, switching the IME through Super+Space causes Firefox to temporarily lose focus. Since the blur event is sent to Discord and the text input loses focus. In this case Discord would listen to keydown and put whatever key it received into the input box. However, this behavior is incompatible with Japanese IME, since the IME is disabled when there's no focus on text input. (This part of the bad behavior also happens with Chrome.) The issue with Firefox is that it would trigger this broken behavior every time I switch IME because it sends a blur event, while Chrome presumably does not do so.

Browser Configuration

• gfx.webrender.all: true
• gfx.webrender.blob-images: true
• gfx.webrender.enabled: false
• image.mem.shared: true
• buildID: 20201116093344
• channel: default
• hasTouchScreen: false
• mixed active content blocked: false
• mixed passive content blocked: false
• tracking content blocked: false

View console log messages

From webcompat.com with ❤️

[cipriansv]

@denschub, could you please take a look at this one?

[softvision-oana-arbuzov]

Ping @denschub

[softvision-raul-bucata]

@ishitatsuyuki Thank you for your report. After installing the correct IBUS and IME on my Linux device, I could not reproduce the issue, as seen in the gif attached:

Could you please tell us what device are you using, which input source from Japanese did you use ( there are about 8 suboptions on my device for the Japanese language - I have selected Mozc), and which input mode did you select ( Kana or Romaji- in my case I have selected Kana).

Tested with:
Browser / Version:Nightly 87.0a1 (2021-02-14) (64-bit))/
Operating System: Ubuntu 20.04.1 LTS x64

Notes:
The same behavior is displayed in Chrome

[ishitatsuyuki]

To clarify, the issue is about the first character being accepted as direct input. The key is the textfield focus: in Firefox you lose the text field focus if you switch IME, but on Chrome you should not.

[softvision-raul-bucata]

@ishitatsuyuki Thank you for the clarification. I was indeed able to reproduce the issue, as presented in the gif below:

It seems that the insertion point is not flashing after switching languages with the command mentioned above ( Superkey + Spacebar - in my case the Superkey is the Windows logo key from the keyboard) meaning that the text field is not ready to accept input. In order to solve the issue, I have to click again in the text field in order to bring it in a focus state (ready to receive text input).

Notes:
The issue is not reproducible in Chrome; after switching to the desired language, the text field is focused and ready to receive input.

Moving this to NeedsDiagnosis for further investigations.

[karlcow]

@masayuki-nakano You will probably have a quicker answer here than me trying to debug. Does it ring a bell?

[masayuki-nakano]

I don't have Discord account so that I've not tested it yet. As far as I've tested with simple testcases, focus event is fired as expected when the ibus popup is closed. So, Discord might do something at focus and/or blur, e.g., changing selection or something, ant that may cause different behavior on Gecko and Blink.

[karlcow]

Thanks that will help.

[denschub]

I tried looking at this, but given the enormous complexity of their JS, I didn't get very far. :/ I reached out to them and asked if we could get a Discord engineer to look at this, which is probably the way to go here. Marking this as sitewait for now.

[ishitatsuyuki]

Just FWIW, when I originally investigated this I thought it's just a matter of issuing blur (Firefox) when it should not (Chromium does not if I checked correctly). You can check the events going on with the "log events" feature of DevTools.

[denschub]

Yeah, but we don't have a general issue with blur events as far as I can tell. I tried understanding which of their code is "going wrong", but given this is heavily minified and somewhat obfuscated, this is a bit like trying to destroy a brick wall with a toothpick. If they don't respond, we can try using some more advanced debugging techniques, but in our experience, it's sometimes a good idea to just reach out to the devs :)

[masayuki-nakano]

@ishitatsuyuki I wonder, does the Firefox window get focus back after changing input mode with the popup without your click? If no, could you check focusmanager.testmode in about:confing? I saw a bug report about focus issue with IME which was caused by the pref.

[ishitatsuyuki]

OK, I just tested this again and it no longer reproduces, so it might got fixed on Discord's end. For the reference, Firefox still issues blur/focus on the Window element while Chromium does none of that.

Versions:

GNOME 40.3.0 on Wayland + IBus 1.5.24
firefox-developer-edition 91.0b9-1 with MOZ_ENABLE_WAYLAND=1

I didn't dig into event details but it seems that input also works without issue on other of my setups, including GNOME X11 + IBus and KDE X11 + fcitx.

[masayuki-nakano]

Thank you for the quick reply. Some distributors may apply patches to GTK/GDK, etc. That may cause different behavior between Firefox and Chromium sine they use different toolkit for making GUI. So, you see something wrong only on Firefox around the window/focus, feel free to file a bug as DOM: UI Events & Focus Handling in bugzilla.mozilla.org.