Test one browser and report a compatibility row: a plain text field, a textarea and a rich editor

Read CONTRIBUTING.md and the compatibility matrix issue (#599), then build with swift build -c release --product uttrflow-dev and grant Accessibility to the binary. Choose one app and test its single-line input, textarea, and rich editor with the listed probe and insert commands. Done means reporting the completed row in a comment or adding it to Docs/compatibility.md; run make verify if you open a documentation PR.

What this is

One row for the compatibility matrix (#599), measured in a browser (any engine you use). Uttrflow's dictation, clipboard paste and AI suggestions all depend on how other apps publish text, and the only way to know what a given app does is to try it. No code changes are needed, just one app you already use.

Test three fields on one page in one browser: a single-line input, a <textarea>, and a rich contenteditable editor such as a web mail compose box. Also try an <iframe>-embedded editor if you know one. These are where #601 (a write that lands late) and #603 (the word under the caret read instead of the field) would show up.

Please say in a comment which app you are taking, so two people do not test the same one. Another app of the same class is a separate row, and welcome on this issue too.

Where to start

• Read first: CONTRIBUTING.md for building, and the compatibility matrix issue (MATRIX) for the table you are filling.
• Build the tool: swift build -c release --product uttrflow-dev.
• Grant Accessibility: System Settings › Privacy & Security › Accessibility, add .build/release/uttrflow-dev. Accessibility is granted per binary, so the app's own grant does not cover it.
• Test data: use invented text only, such as the quick brown fox or support@example.com. No real names, addresses or messages.

What to run, in one field of one app

1. Click into the field before each countdown ends.
2. uttrflow-dev probe surface --seconds 30: note whether a focused field, value, caret rectangle and text style are reported.
3. uttrflow-dev insert --via accessibility "one two three four five six seven": did it land, get refused, report success and change nothing, or land a moment later?
4. uttrflow-dev insert --via paste "one two three four five six seven": did it land? What did the tool print about confirmation?
5. uttrflow-dev insert "one two three four five six seven" (the full route): did the words appear once, twice, or not at all?
6. If you use AI suggestions: accept one suggestion and describe exactly what arrived and where the ghost was drawn.
7. uttrflow-dev probe ime while composing with an input method, if you use one.

What to report

Paste this filled in as a comment, or open a PR adding the row to Docs/compatibility.md:

App / version:
macOS version / Mac:
Keyboard layout / input source:
Field tested:
Focused field published:
Accessibility write:
Paste:
Paste confirmation:
Full route result:
Caret rectangle:
Value and selection readable:
Marked text published:
Typed completion:
Notes:

Size: about an hour for one app. One app per comment is plenty, and partial rows are welcome; leave a cell blank rather than guessing.

make verify only matters if you open a PR against the doc.