1910865 - js.design - Unable to input chinese characters in the search bar

Status: VERIFIED FIXED

(Web Compatibility :: Site Reports, defect, P2)

Description

[Calin Tanase]

Attachment: FF vs Chrome.mp4

Environment:
Operating system: Windows 11/10
Firefox version: Firefox 128.0.2 (release)/130

Preconditions:

• Clean profile
• Chinese (Simplified/China)/Microsoft Pinyin keyboard enabled
• Make sure chinese mode is enabled when typing

Steps to reproduce:

1. Navigate to: https://js.design/community?category=explore
2. Click on the search bar.
3. Type "a" and press any number from 1-7 to validate the chinese character. (you can also choose by clicking directly on the desired character)

Expected Behavior:
The letter "a" gets changed to the chinese character.

Actual Behavior:
The letter "a" does not gets changed to the chinese character.

Notes:

• Reproducible on the latest Firefox Release and Nightly
• Reproducible regardless of the ETP setting
• Works as expected using Chrome

---

Created from webcompat-user-report:adf0058f-e551-4693-8248-6b1f44cf54ee

Comment 1

[Jeff Muizelaar [:jrmuizel]]

Masayuki, can you take a look?

Comment 2

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(sickish, maybe slower respose)]

Indeed, I reproduce this bug on Android too. So, I see this without kind of inputting characters, i.e., even with English words.

Comment 3

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(sickish, maybe slower respose)]

This is a bug of the web site, they depend on Chrome specific behavior at least under current spec state.

According to the debugger, HTMLInputElement.value is set when we are dispatching compositionend. At this time, our HTMLInputElement already has the commit string, but the setting value is old value, i.e., the last value which was introduced with the last input event. So, I think that this is caused by the incompatible event order issue because Chrome dispatches input before compositionend whose isComposing is true, but we dispatch input after compositionend whose isComposing is false. Therefore, we cannot fix this in our side until the spec issue is closed.

I think that the web site should use .data value of compositionend event when they set HTMLInputElement.value.

Comment 4

[Jeff Muizelaar [:jrmuizel]]

Can we switch to the Chrome behaviour until the spec issue is resolved?

Comment 5

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(sickish, maybe slower respose)]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #4)

Can we switch to the Chrome behaviour until the spec issue is resolved?

The reason why I filed the spec issue is, it may be hard to port our chrome script to the new behavior due to unusable .isComposing attribute value. Although I'm not sure whether we need that, current Chrome behavior is obviously unusable for editor developers to support IME. Actually, this search form needs to listen to compositionend events rather than only input events.

Comment 6

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(sickish, maybe slower respose)]

Ah, but we could dispatch a redundant input event before compositionend. I'll try in a new bug.

Comment 7

[Calin Tanase]

Attachment: FF Nightly (Desktop and Mobile).mp4

It works now on both mobile and desktop when following STR.

Comment 8

[Raul Bucata]

Verified as FIXED using the RC Build

Tested with:

Browser / Version: Firefox 137.0-candidate build 1
Operating System: Windows 10 PRO x64