FormStage

Observation book / 15 October 2026

The call ended.
What did the page do?

Nine native cases on Chrome DevTools MCP 1.11.0 and Chrome for Testing 156.0.8078.4, macOS ARM64. These are dated observations, not promises about every version or website.

01

An error can follow a mutation.

In our empty textarea, a native type_text call with text test and the invalid submitKey: "XXX" returned an error. Reading the page immediately afterward found four characters. Repeating the same failed call left eight.

Before: ""
Call:   type_text(text="test", submitKey="XXX")
After:  "test"       Tool result: error
Retry:  same call
After:  "testtest"   Tool result: error

That sequence gives the error a narrower meaning: the whole requested operation did not complete. It does not prove the field stayed unchanged.

Use the retry-note specimen →

02

The same newline, two different paths.

The specimen is a text input inside a form with a submit button. The short fill_form value "5\n" left 5 and dispatched a submit event. The form intercepted it, so no request left the page.

A 121-character value—120 letters followed by a newline—left the letters without a submit. Plain "5" was the normal-fill control and did not submit either.

short:   "5\n"             → 1 submit
long:    "x" × 120 + "\n"   → 0 submits
control: "5"               → 0 submits

Length can change the native input path. Do not treat this as a universal “safe length” rule: we measured these values in this fixture. Multiline textareas, other form markup and future versions are different experiments.

Use the submit-form specimen →

03

A tab character did not move focus.

Our native fill_form call with "A\tB" placed a literal tab between A and B in the first field. The family-name field stayed empty and focus stayed on the first field.

The control used separate actions: type A, press_key with Tab, then type B. That moved focus and split the letters across the two fields.

fill_form "A\tB"      first: "A\tB"  last: ""
type A / Tab / type B first: "A"     last: "B"

This is a useful counterexample. A report of an effect is a reason to reproduce it, not a substitute for the result on your installed version.

Use the focus-pair specimen →

04

An upload target can be a click target.

We deliberately passed the submit button’s fresh UID to upload_file. Native MCP clicked it while looking for a file chooser. The fixture recorded one intercepted submit before the tool reported failure.

Targeting the real file input instead attached our synthetic text file and recorded no submit. Its contents were not read by the page.

wrong target: submit button → submit 1, tool error
right target: file input    → filename present, submit 0

Some real applications intentionally use a button to open a chooser. The lesson is to identify the button’s behavior, not to declare every non-input target invalid. Our deliberately wrong target submits instead.

Use the file-input specimen → · Open the wrong-target control →

Repeat, then compare.

The downloadable native runner records both the real tool responses and page effects. A changed observation on a newer version is not automatically a regression: a fixed bug should change the result.

Keep the evidence separate.

A submit event is not server acceptance or email delivery. Take the four-part record to your own staging form. See method and limits for what the public playground can observe.