Support Begin Batch Edit and End Batch Edit for Edit Context

[hd-chuong]

Problem Statement

When updating multiple properties of an EditContext instance (such as text, selection offsets, control bounds, or character bounds), each individual method call (updateText(), updateSelection(), updateCharacterBounds(), etc.) can immediately trigger internal browser updates or synchronous inter-process communication (IPC) calls to the underlying OS Text Input Service / IME.

In complex rich-text editors, performing multiple atomic updates can result in:

Problem 1 (IME -> Web App) When native IMEs perform batch edits (e.g., Android InputConnection.beginBatchEdit()), browsers dispatch multiple individual textupdate events without signaling batch start/end boundaries, forcing web apps into invalid intermediate states that are different from IMEs' initial state snapshot.

Problem 2 (Web App -> IME) Intermediate invalid states exposed to the OS text input service or accessibility layer before the entire update sequence is complete.
Native operating system text editing frameworks solve this by offering batching mechanisms (such as Android’s InputConnection.beginBatchEdit() and endBatchEdit()).

Proposal

We propose introducing events for beginBatchEdit and endBatchEdit so developers can respond to batch edit state changes.

---

[ltenmoz]

I wonder if this is better handled by browsers notifying the text input service asynchronously of all these changes. In fact, that's how the spec is written today, so this would more be a bug in the browser if it notifies synchronously. So long as you can call all the update*() methods synchronously in a row, then it shouldn't be an issue if browsers are following the spec (which, it's very possible that they're not).

[hd-chuong]

Thank you for responding quickly, and sorry for supplying inadequate description of the problem statement.

In the initial problem statement, I only mentioned the direction from Web App -> IME. I believe we are, indeed, more concerned about the opposite direction: IME -> Web App. The issue that we are facing is that Web Apps apply the IME operations and update their internal state model synchronously as long as the IME operations arrive (e.g. via textupdate events). Since IMEs emit beginBatchEdit and endBatchEdit, they expect the web app state to remain unchanged, but this is not the case because there is no indication of batch begin and batch end.

1. Does your recommendation that "browsers notifying the text input service asynchronously of all these changes" apply in the "IME -> Web App" direction?

2. Without a clear batcheditbegin / batcheditend event, on which basis can the web app detects batch events so they will have different treatment of in-batch operations vs. handling operations as standalone ones?

Thank you for your opinion on these.

[ltenmoz]

Still, I think this is something that is better handled by the browser. Specifically, the browser should wait until the batch has ended, and then send all of the updates from the IME (I believe this is what we do in Gecko with contenteditable today) without rendering in between. Given that the intermediate state shouldn't be rendered, there's no need for the web app to know about it. Is there some reason why this wouldn't work for you?