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.