A reply that text was sent did not establish that the intended text appeared. Line breaks could disappear, an editor could commit late or only part of the text could arrive. I added readback against the expected value without reinserting the content on mismatch.
Transmission and commitment can occur at different times
After Input.insertText is sent, an editor's internal state can take time to catch up. Proxy editors separating a visible module from the input surface can commit native input asynchronously. Transmission and readback need separate checks to explain that interval.
The driver compares actual content through verifyFill. Specific native-editor paths can repeat readback within a short bound while waiting for commitment. They do not insert the text again because acknowledgment is late. The code distinguishes reading a result from replaying an action.
Normalization must not silently rewrite the manuscript
Ordinary inputs and textareas compare their real value with the expected string. A recognized editor module uses its paragraph representation and narrowly normalizes CRLF to LF. It does not trim arbitrary whitespace and empty paragraphs merely to declare success.
An empty contenteditable can contain a structural break or empty paragraph, so a narrow empty-value case exists. Multiple paragraphs, real spaces and embedded media are not all erased as empty. Representation differences need accommodation without concealing differences in the manuscript itself.
Return equality rather than a general value extraction
browser.verifyField returns check and match information. Reading an actual value internally for comparison differs from exporting the whole body as general extraction. Some editor-layout verification can return additional structural differences, so the result is not universally just one boolean.
The page API accepts the fill reply's new observation and verifies with a fresh reference. A false match ends with FIELD_MISMATCH rather than a misleading verified label or another insertion. Readback still depends on current document and reference conditions.
Use failure diagnostics to narrow the difference
An unverified native-editor input can retain a bounded summary with expected and actual character and line counts, the first difference and selected character codes. It does not begin by copying the whole manuscript into a diagnostic log.
That summary is not a universal anonymization result either. Counts and codes remain information, so public examples use synthetic content instead of real manuscripts. A diagnostic record does not establish a repaired cause. I wanted a readable failure without turning it into justification for automatic reinsertion.
A matching field does not establish remote storage
Expected text in a field does not mean the service saved it. An unsent chat or unfinished draft can match perfectly. Publication, scheduling and upload need their own outcome checks. Input verification must not become whole-workflow completion.
The existing page-API fixture checks fresh-reference verification and mutation count. Historical ordinary-input and Unicode tests retain their own scopes. This article compares those tests with current readback code; it does not use a customer manuscript for a new external-save experiment.
Show the customer which stage actually finished
Separate wording for input complete and save confirmed helps a user understand the current state. Agents need that distinction too. Field equality, storage and public availability cannot share one undifferentiated success label.
I designed readback as a boundary exposing differences rather than quietly fixing them. Read while commitment is late, stop on mismatch and separately verify required storage. Each editor has representation rules and limits, so a new integration needs a synthetic manuscript reproduction and actual checks of those specific rules.