Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[regression] Preact 10.14.1 breaks IME input on controlled text inputs that don't update the controlled value during composition #4008

Closed
1 task
birtles opened this issue May 18, 2023 · 1 comment · Fixed by #4009

Comments

@birtles
Copy link

birtles commented May 18, 2023

  • Check if updating to the latest Preact version resolves the issue (it does not)

Describe the bug
When typing in a controlled text input using an IME in Preact 10.14.1, if the app does not update the text input's value during composition, Preact will forcefully update the value which will cause composition to be terminated and nothing to be input.

To Reproduce

Steps to reproduce the behavior:

  1. Go to https://codesandbox.io/s/charming-ace-w086of
  2. Click on the text input box
  3. Activate an IME that triggers composition such as a Japanese IME
  4. Attempt to type テスト

Expected behavior

It should be possible to compose the string テスト and commit it

Actual behavior

The input is never updated.

If we drop the following early return from onChangeText it works as expected:

    if (isComposing.current) {
      return;
    }

If we switch the preact dependency to 10.13.2 it also works as expected.

Note that unfortunately this is not as simple as checking the isComposing value of the input events. Composition event order and the value of isComposing is a massive interop nightmare (see w3c/uievents#202 for a start) with quite different behavior on each of the browser engines, and different behavior again on their mobile versions.

@JoviDeCroock
Copy link
Member

Hmm, yes in Preact 10.13.2 we did not have the whole previous value restoration that made the value be more dependent on the VDOM. I was trying to see whether React had a good solution to this and it seems like they have been in this situation for a while as well facebook/react#3926 (comment). Going to try and think about a solution but worst case scenario we revert the controlled inputs system for the time being until we have a better understanding of how to deal with these. Thank you so much for the great issue description.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants