Web-Facing Change PSA: InputEvent types for deletion commands on non-collapsed selections
Chromestatus
Gecko: No signal (https://developer.mozilla.org/en-US/docs/Web/API/InputEvent/inputType)
WebKit: Shipped/Shipping (https://webkit.org/blog/7358/enhanced-editing-with-input-events)
Web developers: No signals
Other signals:
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
No information provided| Shipping on desktop | 145 |
| Shipping on Android | 145 |
| Shipping on iOS | 145 |
Mike Taylor
On 2/4/26 9:58 p.m., Chromestatus wrote:
Contact emailsprana...@microsoft.com
Specificationhttps://w3c.github.io/input-events/#interface-InputEvent-Attributes
SummaryReports accurate inputType values for deletion keyboard shortcuts on selected text. When deletion commands like Ctrl+Backspace or Ctrl+Delete are used with selected text in contenteditable elements, the beforeinput and input events now report deleteContentBackward or deleteContentForward instead of deleteWordBackward or deleteWordForward. This enables web developers to correctly understand what editing operation occurred and implement reliable undo/redo or custom editing behaviors.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6984317b.050a0220.baa59.057d.GAE%40google.com.
Pranav Modi
Doing a compat
analysis for this change does not look straightforward to me as the change that
is being proposed, happens in a specific use-case where there is a modifier+key
combination (Ctrl+Backspace, Ctrl+Delete, etc.) while having a non-collapsed selection.
That said, for a site to actually break from this, it would need to:
- Listen for beforeinput/input events,
- Specifically branch on inputType === "deleteWordBackward" (or similar granularity types). This condition will be impacted only in case of presence of non-collapsed selection and deletion via modifier keys.
- Not have a handler for deleteContentBackward/deleteContentForward — which they'd already need for plain Backspace/Delete (Any site handling input events for deletion already handles deleteContentBackward/deleteContentForward (since those are what plain Backspace/Delete produce), so receiving these types for Ctrl+Backspace with a selection will naturally fall into existing code paths.).
As this appears to be rare scenario, our motivation is to make the event spec compliant along with publishing a PSA which should be a sufficient enough mitigation. Also note that this change is behind a runtime flag (InputEventsDeleteNonCollapsedSelection ), so we can quickly disable it if any issues surface post-launch.
Daniel Bratell
Searching the HTML Archive and github can help you get an idea about how they are used and the effects of renaming or removing them.
Just looking at https://github.com/search?q=deleteWordBackward+language%3AJavaScript&type=code&l=JavaScript there is quite a bit of code. I didn't check to see if any of them would break, but hopefully such an analysis is not too hard.
/Daniel
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/cfdf5dba-277d-43d0-ab94-453051b6a22dn%40chromium.org.
PhistucK
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/12404586-2b3c-4fe8-9003-eb45c67840fe%40gmail.com.
Pranav Modi
Compat analysis: Analyzed ~2,200 files across JavaScript and TypeScript on GitHub for both deleteWordBackward and deleteWordForward usage, with full source context.
Change scope: In Chromium only, when a non-collapsed selection exists and the user presses Ctrl+Backspace/Delete, inputType changes from deleteWordBackward/Forward to deleteContentBackward/Forward. Caret behavior is unchanged.
Results: Of ~2,200 files, 10 unique repos (after deduplicating forks) check deleteWord* without also handling deleteContent*. Of those:
- 3 are typing test apps where the trigger scenario (select text → Ctrl+Backspace) doesn't arise in normal use
- 5 have native browser fallback — selected text still gets deleted, just through the native path
- 2 are niche tools (academic NLP tool, personal terminal emulator) with a minor behavior difference
Major frameworks (CKEditor, Lexical, Slate, Odoo, monkeytype, GNOME/evolution) all handle this correctly already. No major websites or widely-used libraries are affected.
Interestingly, I noticed that the shipped feature already has the runtime flag enabled (stable since M145), and there have been no bugs or regressions filed against it, which further confirms that the change hasn't caused any meaningful breakage.
The runtime flag (InputEventsDeleteNonCollapsedSelection) remains available as a kill-switch if needed.
Daniel Bratell
Good analysis. It sounds like the change will be web compatible, which is good news.
/Daniel
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4259dd4e-25a3-4d04-8d79-21e0cb1813dfn%40chromium.org.