this one is weird. working version here that just preventDefaults everything: https://jsfiddle.net/m9xjqcz6/1/

on the number keyboard, I can type dot and hyphen, but not underscore and comma. Backspace also works. I suspect underscore and comma are not allowed by type=number. And this only repros on android. Maybe something ime composition related, changwan?

overall, ime composition does not work on individual key event level, so I'm not entirely sure if the interactions here well defined, number input is probably ok, but if you want to control do full words and whatnot in js through individual key events, that's probably doomed for failure

number keys are sent from Google Keyboard as 'sendKeyEvent' while the operators / parentheses are sent as 'commitText'. This is just Google Keyboard behavior and may vary from keyboard to keyboard.

Unfortunately, we're not supporting preventDefault case for commitText / setComposingText as of today.
(These are Android's InputConnection APIs: https://developer.android.com/reference/android/view/inputmethod/InputConnection.html)

One prerequisite of supporting preventDefault is to enable ImeThread feature. The old replica model cannot support preventDefault case at all. We're targeting ImeThread launch in M54 ( issue 551193 ).

The bigger problem is that Android does not support a natural way of 'ignoring' the composition change. Keyboard apps may wait forever for the change to happen and there is no way of telling that the command has been ignored.

One approximation is as follows:

1) Renderer: Ignore subsequent composition when key event is prevent-defaulted, ask browser to restart input.
2) Browser: restart input.

But this is not a perfect solution: if you type really fast, some residual composition and key inputs in the queue may be lost in the restarting process. Therefore, I'm not sure if this is something we want to pursue.

sirius.programmer@, could you let us know the exact use case where prevent default is critical?

simulate maxlength for non-supported types ( crbug.com/638246 ) ?

A full solution to this problem is going to need the new JS events that are currently getting specced.

comment #7; beforeinput is available behind the experimental web platform flag. Although it doesn't sound like it will be too much help here as it isn't cancelable when an IME composition is occurring.

We might be able to cancel the DOM update from blink side (after confirm composition), which should solve this problem.

However current blink implementation has some bug, where it's canceling replaceText. Ideally it should remove marked text and prevent inserting conformed text.

See 'beforeinput' spec proposal:
https://github.com/w3c/editing/issues/137#issuecomment-236704445

Dropping webview label since this affects chrome too

Chanwang :
>>sirius.programmer@, could you let us know the exact use case where prevent default is critical?

 use case : In our app we have 4 numeric input fields, each field should allow only a max length for 4 numbers , here we need to prevent the user from inputting special characters such as  '.' , '+' and '-'.   We need to use prevent default on the event object by validating key code of the input character

Re #9, it turned out that events are not cancellable during composition in the new spec. But how about at the beginning when starting from empty string / existing text? Are they cancellable?

If not, I'm afraid that this scenario cannot be fulfilled.

Also, we should figure out how to correctly cancel composition in the Android framework.

1) Return false in setComposingText() / commitText() --> This may slow down the whole typing experience.
2) Restart input and ignore IME typing until restarting occurs. --> This is not correctly implemented yet. (Issue 650204 is highly related.)

Re #15. From InputEvent's (or 'beforeinput') perspective JS should only care about composition start and composition end. (Everything is non-cancelable during composition.)

1. For composition start, 'beforeinput' [inputType='deleteByComposition'] will be fired for starting from existing text.
  * If canceled, the existing text won't get replaced/removed, and UA should start composition from empty string but re-insert selected text immediately.

2. For composition end, 'beforeinput' [inputType='insertFromComposition'] will be fired, with data=|Committed Text|.
  * If canceled, nothing will be inserted. (The marked text will always get removed)

InputEvent spec:
https://w3c.github.io/input-events/index.html#h-note4

Thanks for the quick response. Then this should still be possible with the new spec once we fix 2) in #15.

Let me take a look as this is highly related to issue 650204.