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

Support for composition events #1978

Open
birtles opened this issue Oct 4, 2019 · 6 comments
Open

Support for composition events #1978

birtles opened this issue Oct 4, 2019 · 6 comments
Labels
compat needs-more-info The issue doesn't contain enough information to be able to help workaround

Comments

@birtles
Copy link

birtles commented Oct 4, 2019

So far as I can tell, although jsx.d.ts includes a definition for composition events such as onCompositionEnd, they are not implemented.

Furthermore, while isComposing is available through InputEvent, it is not normalized between browsers so, for example, in Firefox there will be an input event where it is true but there is not in Chrome. Without composition events it is not possible to work around this and, for example, only update search results once the current composition has been committed.

Test case:

https://codesandbox.io/s/bold-currying-vqfq8

@birtles
Copy link
Author

birtles commented Oct 4, 2019

Test case:

https://codesandbox.io/s/bold-currying-vqfq8

Typing and committing あ in the above test case gives:

Firefox:

input (data: あ, isComposing: true)
input (data: あ, isComposing: false)

Chrome:

input (data: あ, isComposing: true)
input (data: あ, isComposing: true)

@birtles
Copy link
Author

birtles commented Oct 4, 2019

For what it's worth, the browser interop issue has some discussion at:
w3c/uievents#202

It would be nice to have these events regardless of the outcome of that, however.

@marvinhagemeister
Copy link
Member

Thanks for posting this. I've read through the linked w3c issue a couple of times, but I'm not sure what the expected behavior is. There seem to be arguments made in favor of both sides. From what I can gather so far, the firefox implementation is the preferred one. Is that correct?

@birtles
Copy link
Author

birtles commented Oct 4, 2019

Sorry, I possibly confused the issue by linking to that spec discussion. For what it's worth, as a Web developer, I find the Firefox behavior more useful (e.g. for ignoring uncommitted input).

As far as Preact is concerned, however, the issue is simply that authors can't rely on isComposing both due to compat issues and because the Chrome behavior makes it impossible to ignore uncommitted input. As a result authors needs to listen to composition events instead but Preact does not appear to implement them (unlike React). Instead, it seems authors need to add native event listeners to elements, e.g.: birchill/hikibiki-app@4b324e7

@developit
Copy link
Member

Hi @birtles - I think this is actually a case sensitivity issue. My guess is that you'll find this works:

<input oncompositionend={() => { ... }} />

@developit developit added compat needs-more-info The issue doesn't contain enough information to be able to help workaround labels Oct 5, 2019
@birtles
Copy link
Author

birtles commented Oct 5, 2019

Hi @birtles - I think this is actually a case sensitivity issue. My guess is that you'll find this works:

<input oncompositionend={() => { ... }} />

Oh yes, you're right. That does indeed work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compat needs-more-info The issue doesn't contain enough information to be able to help workaround
Projects
None yet
Development

No branches or pull requests

3 participants