Keep native browser behavior for prevented beforeinput events

[Comandeer]

Sometimes user input is connected with a native browser/OS behavior, e.g.

• pressing Enter inserts a new line and triggers autocorrection,
• double pressing space inserts a period.

However, RTEs often want to prevent the beforeinput events to be able to customize the input, e.g. preventing beforeinput after pressing Enter to insert a new paragraph. Such prevention disables the native browser behavior. There should be a way to keep the behavior but without the input, e.g.

• pressing Enter does not insert a new line but triggers autocorrection,
• double pressing space insert a period regardless of how many beforeinput events have been prevented.

Some loose ideas of how such API could work:

• a new parameter to the event.preventDefault() to allow native behavior – event.preventDefault( { behavior: true } ),
• a new method on the event to prevent only input – event.preventInput(),
• a new method on the event to trigger native behavior manually – event.fireConnectedBehavior().

[johanneswilm]

From TPAC 2024 minutes:

w3c/input-events#161

Tomasz: When doing beforeinput cancelltion, it also cancels other related things such as autocorrect, two spaces give a perido, etc.

Sanket: We should keep to existing model. Maybe add a second APi to do auto correction. Would that fix it?

Tomasz: Only in this case.There are other things like auto-capitalization, etc.

Dan: What if you had three events?

Johannes: What if the editor doesn’t update the dom on one of the first two events? Could this not be solved with EditContext instead?

Sanket: It still makes sense to me. It only happens on specific keys. … Maybe something to put on EditContext.

Sanket: I think we need a way to trigger the autocorrect.

Dan: Same privacy issues (on Mac)

Ryosuke: At the same time we need to support this.

Johannes: Ryosuke, do you agree that it should no t be an issue in EditContext [explain]?

Ryosuke: Yes

Olli: But we also need to support this in other places - like textinput, etc.

Siye: The event should still be triggered, even if prevent default was called on an enter-event.

Dan: That is risky. We need more time. Difficult to fix without privacy issues.

RESOLUTION: We try to think about a solution. Table until next meeting.

Dan difference to spell checking: less privacy issue as the JS cannot see wha words are underlined and the user has to decide

[smaug----]

This is possibly a tiny bit related to #160, when it comes to handling enter key.