User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.93 Safari/537.36

Steps to reproduce:

Repro with https://jsfiddle.net/tdp0z98q/. This issue affects MacOS accent input on Google Docs.

1. Open the fiddle in Firefox on a Mac. (The fiddle just sets up a contenteditable div, cancels beforeinput events, and resets the selection on keypress).
2. Place the cursor between the two characters in the content editable.
3. Type a character.
   • Notice that no character is inserted, because we call preventDefault on beforeinput.
4. Long press on a vowel until the accent menu pops up, then click on one of the options.
   • Notice that the selected option replaces the previous character, event though we called preventDefault on beforeinput.
5. Continue inserting accented characters.
   • Notice that the position where the character is replaced continuously alternates between before the caret and after the caret.

Actual results:

• The accented character is inserted despite preventDefault called on the beforeinput event. (I haven't found any event I could block to prevent this from happening).
• The accent menu alternates between replacing the character before the caret and after the caret.

Expected results:

• The selection from the accent menu should not be inserted if we call preventDefault on the beforeinput event, since beforeinput is defined to be cancelable. This is the behavior in Safari and Chrome.
• The accent menu should always point at the character before the caret.

The Bugbug bot thinks this bug should belong to the 'Core::DOM: Events' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Can't confirm as I have no macOS access, so just NIing:

Change the status for beta to have the same as nightly and release.
For more information, please visit auto_nag documentation.

I guess that Chrome/Safari do not use composition events for the input, but Gecko does. Then it becomes non-cancelable only on Gecko. But this is not an illegal case, although, serious web-compat issue.

Perhaps, this is a dup of bug 1390124.

since beforeinput is defined to be cancelable

FYI: This is not correct. It depends on inputType value. See the spec.

Oh, I pointed different bug. That is bug 1520983.

Fixed by bug 1520983.