Input events

[jgraham]

One area that's believed to cause significant compat problems and difficulties for writing reliable editors is differences between input events, and their order, in different browsers. As part of this investigation we should:

• Identify the specifications covering these events, and ensure that they match the desired behaviour
• Identify the existing testcases covering these events, and ensure they match the specifications
• Add additional test coverage where there are known gaps

The aim is that the identified tests would be a candidate for an Interop 2023 focus area that browsers would be able to commit to.

[jgraham]

Please let me know if the summary as written isn't right, doesn't cover something important, or covers something it shouldn't.

[jgraham]

An issue we'd like to nominate for inclusion here is w3c/uievents#202 which led to https://bugzilla.mozilla.org/show_bug.cgi?id=1511157 and is related to https://bugs.chromium.org/p/chromium/issues/detail?id=929404

[jgraham]

From our point of view, getting that issue resolved would be a sufficient goal for this part of the project.

[whsieh]

Another interesting issue might be aligning whether events are dispatched when deleting backwards in an empty contenteditable or text field; when focusing the textarea on https://whsieh.github.io/examples/input-events and deleting backwards in Safari, for instance, neither input nor beforeinput are dispatched (which just seems like a bug).

In both Firefox and Chrome on macOS, the beforeinput event is dispatched, but not the input event. We should probably all align on this behavior.

[masayuki-nakano]

@whsieh

Currently, Firefox does not check strictly whether Delete or Backspace will delete something or nothing because it's hard to dispatch beforeinput event at first modification of the DOM tree. That's the reason why Firefox dispatches beforeinput in the case.

On the other hand, cut, copy and paste events are always fired for making web apps possible to handle them when the user indent to do it with browser's default shortcut keys or UI (such as menu) even if the commands are not available, e.g., due to Selection is collapsed or non-editable element has focus, the reason is for making web apps may want to handle them with their own data.

For consistency with the clipboard events, dispatching only beforeinput event must be reasonable in the case, e.g., web apps may put multiple editable elements and they may want to navigate them at pressing Backspace or Delete like credit card number inputs.

And it seems that browsers should dispatch beforeinput events whose inputType is historyUndo and historyRedo even if there is no transactions in their builtin editor.

[johanneswilm]

At TPAC, the Editing Working Group decided to move the event order of composition and input events into the uievents spec. So this is currently part of the TODO list of @garykac [1]. Also, the question of whether the last beforeinput event of a composition should be cancelable is still unresolved [2]. So based on that I am not sure whether it is actually possible to present tests rights now.

[1] w3c/input-events#22 w3c/input-events#135 https://www.w3.org/2022/09/15-editing-minutes.html#a01

[2] w3c/input-events#134

[jgraham]

https://wpt.fyi/results/input-events/input-events-typing.html?label=experimental&label=master&aligned&view=subtest should be updated to match the expected behaviour.

https://wpt.fyi/results/input-events?label=experimental&label=master&aligned&view=subtest has additional tests.

The composition events tests will require IME primitives.

[jgraham]

Score here is still 0% until we have some tests added / updated and progress on the spec changes.

[Azmisov]

Quirks I have observed:

• Pressing delete key in Chrome will use beforeinput.deleteContentForward followed by input.deleteContentBackward (should match)
• If I have a text element  text and backspace up to, but not including, the space, Chrome Android will fire beforeinput.insertCompositionText followed by input.deleteContentBackward (should match)
• Pasting in Chrome Android seems to use a series of composition events instead of insertFromPaste
• Safari uses insertText instead of insertReplacementText when correcting a typo
• Delete soft vs hard line forward/backward is not consistent among browsers. ctrl+shift+backspace gives you soft delete in Firefox, hard delete in Chrome; Safari says it is a deleteHardLineBackward, but it actually behaves like a soft delete.
• Safari delete key does a deleteContentBackward with backspace behavior
• Changing the cursor position during composition in Safari will emit compositionend without deleteCompositionText or insertFromComposition
• Changing the cursor position during composition in Chrome Android will stop composition, but no compositionend is emitted.
• No browser is emitting deleteByComposition
• Firefox compositionend occurs before the final input.insertCompositionText, with isComposing=false, whereas other browsers all do the compositionend after.
• Manipulating DOM during composition will cancel composition in Chrome Android. In Firefox, composition continues, but events and ranges are in reference to a disconnected DOM element. I suppose more of a gap in the spec, in that its not defined what browsers should do should the DOM change. Chrome behavior is reasonable, though if I am only changing the styles of elements and the textContent and the cursor relative to that textContent is unchanged, I would think the browser should be able to continue composition without canceling; the IME doesn't care about the DOM, so if textContent is the same, I'd expect composition to be able to continue. Firefox I think is poor behavior since the cursor no longer has focus on that disconnected element; it should cancel the composition or gracefully recover if textContent were the same. At the very least, the spec could say "manipulating the DOM between (beforeinput.deleteByComposition, beforeinput.insertFromComposition) will result in undefined behavior". See my suggestions here input-events/issues/134, about a requestCompositionEnd and compositionborder, which I think can also help better define browser behavior for composition: If they wanted to manipulate DOM, they'd call e.requestCompositionEnd() first and wait until beforeinput.insertFromComposition (outside the "undefined" event range); after this event, browser then picks up updated DOM and can continue composition if needed with the possibly modified text.

I've also made an input events tester like @whsieh, see here: https://azmisov.github.io/Input-Events-Tester/. Feel free to use/fork/edit if you want. It will pretty print the DOM HTML, along with target ranges/selection embedded, and a unique id applied to each node. Can be helpful to test how browsers behave with things other than plain text (which I would say is the motivation behind InputEvents). Can be used cleanly from mobile browsers as well.