The attached test-case has a <div contenteditable>.

When the OSX emoji picker is used to add an emoji to this div, Firefox fires composition events, while Chrome and Safari do not.

(One can trigger the picker by pressing ctrl-command-spacebar while the div is focused).

I'm not sure whether this is a bug in Chrome/Safari's handling of the picker, as I'm unclear on how the picker plays with all of the partial-commit stuff in the spec (but it's still an obvious interop issue that is affecting WhatsApp's interaction with the OSX emoji picker).

(In reply to Thomas Wisniewski [:twisniewski] (PTO Dec 24-26, 31-2nd) from comment #0)

The attached test-case has a <div contenteditable>.

Hi Thomas,
Seems you forgot to attach a test case as you planned to? :)

When the OSX emoji picker is used to add an emoji to this div, Firefox fires composition events, while Chrome and Safari do not.

(One can trigger the picker by pressing ctrl-command-spacebar while the div is focused).

I'm not sure whether this is a bug in Chrome/Safari's handling of the picker, as I'm unclear on how the picker plays with all of the partial-commit stuff in the spec (but it's still an obvious interop issue that is affecting WhatsApp's interaction with the OSX emoji picker).

Hi Masayuki,
Can you please check if we're doing the right thing according to the spec? Thank you.

Oops, yes I did somehow miss adding the test. Here it is.

Well, difficult to say...

If input source is not keyboard, we use a set of composition events to represent a text input since really old version. I.e., current our behavior is by design.

Additionally, Japanese IME has similar pallet to input any Unicode characters. So, our behavior was implemented for supporting such function of IME. I.e., this means that broken apps due this difference do not support emoji input from IME anyway. So, I think that they should fix their bug. E.g., Japanese users can input an emoji with typing name of it with IME so that emoji characters can come with composition events in any browsers.

I mean that, perhaps, this incompatible behavior should be fixed after implementing beforeinput. However, such broken apps do not support emoji input via IME anyway.

Thanks for the comment, Masayuki. Let me set dependency with beforeinput event bug so that we remember to revisit it after that is implemented.

Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.

See bug 1547409. Migrating whiteboard priority tags to program flags.

The original issue in https://webcompat.com/issues/13503 has been resolved by the website, though this test case should still be valid.

We haven't seen other reports of this problem pop up yet in the wild.

This incompatibility causes not allowing web apps to cancel the inserting text from emoji picker and accent menu of Western keyboard layouts with beforeinput event listeners since beforeinput events for composition are not cancelable.

I wrote patches, but I'm struggling with intermittent failure of the test. Perhaps, it's caused by the race between focus to a content process and dispatching new event.
https://treeherder.mozilla.org/jobs?repo=try&revision=4f8425d37e38dbaa1fba1c7d527885b54f10bafa

For inserting text from OS in special cases, e.g., when inserting 2 or more characters
per keydown or inserting text without key press, we use a set of composition events on
macOS, but the other browsers don't use composition events. Instead, they expose only
beforeinput event and input event. We should follow their behavior for web-compat
because beforeinput events for IME composition are never cancelable, but the
beforeinput events for the cases are cancelable of the other browsers.

Like the other browsers, we should stop dispatching a set of composition
events when insertText: is called by Emoji picker, accent character
picker of some Western keyboard layouts. Then, corresponding
beforeinput event becomes cancelable like the other browsers'.

Depends on D114826

Backed out for causing build bustages.

Backout link: https://hg.mozilla.org/integration/autoland/rev/77737e5ac216842c046b8a792cad3779db0ef932

Push with failures: https://treeherder.mozilla.org/jobs?repo=autoland&selectedTaskRun=DPl9cWCTTX-gpoj5j5Gb0A.0&revision=c09060ee835814453fa5475bec3e0f580fcba510&searchStr=linux%2Cx64%2Cdebug%2Cbuild-linux64-base-toolchains%2Fdebug%2Cbb

Failure log: https://treeherder.mozilla.org/logviewer?job_id=339977221&repo=autoland&lineNumber=8240

https://hg.mozilla.org/mozilla-central/rev/37f8398e1257
https://hg.mozilla.org/mozilla-central/rev/9fd5512f7f4c