Support Begin Batch Edit and End Batch Edit for Edit Context

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.

Start with the EditContext API proposal and the updateText(), updateSelection(), and updateCharacterBounds() methods described here. Review the Android InputConnection batching reference and the issue discussion to clarify the beginBatchEdit and endBatchEdit event semantics. Done means the Web App and IME batch boundaries and resulting behavior are specified clearly.