Ta strona jest publikowana po angielsku i ukraińsku; poniżej wersja angielska.
What the assistant reads on the screen
For developers, in code: what leaves the browser in each read mode, the exclusions that outrank every mode, append versus fill, and what the assistant is told it changed.
The assistant reads the screen to describe it and to decide where to write. Whether the text in a field leaves the browser is the owner’s decision — the widget sits on the owner’s site and would otherwise be reading what visitors type into contact forms and order addresses into a prompt that reaches a model provider.
The three read modes
Can the assistant see what is in the fields (page_read_values), on the widget’s Page
actions tab:
| Mode | What the manifest carries for a field |
|---|---|
off (the default for every site) |
filled: true/false — whether there is a value, never what |
marked |
the value, only for controls under an element marked data-sa-read (the control itself or any container) |
all |
the value of every readable control, clipped at 2000 characters with clipped: true |
A slider’s current reading, a textarea’s text and a select’s chosen option all follow the same gate.
What is never read, in any mode
<input type="password">, type="hidden", type="file", and anything inside a data-sa-private
element. These outrank the opt-in: marking a password field data-sa-read does nothing. They are
also never acted on.
These exclusions go by a field’s type and by your markup. A card number typed into a plain
type="text" field looks like any other text, so mark a payment form data-sa-private and it
stays out of reach in every read mode — which is also why reading starts switched off.
data-sa-read for text, too
Beyond field values, data-sa-read folds a region’s descriptive text into the manifest — a
hint under a field, a form error, a note beside a switch — up to 400 characters, as a text
entry. That is how «why is Save disabled?» gets an answer that quotes your own validation message.
Append versus fill
fill replaces a field’s value. append adds to the end, and the concatenation happens in the
browser: the existing text never leaves the page. That is what lets the assistant extend a field
with reading switched off, and the only safe way to extend a value the manifest showed as
clipped. append adds no separator of its own and is refused on a dropdown.
What the assistant is told it changed
The widget verifies every write by reading the control back, and reports what it found:
| Flag | Meaning | What the assistant says |
|---|---|---|
replaced: true |
the field held a different, non-empty value before the fill | «I replaced what was there» — never a bare «done» |
unchanged: true |
the field already held exactly that value | «it already says that», and an «add to this field» request is therefore still undone |
| neither | the field was empty or the value is new | «filled» |
The same for check on a box already ticked and select on an option already chosen. Writing
the same text back destroys nothing, so it is not replaced.
Reading without acting
With page actions off, the assistant on an app screen can still read — page_read is served
for a screen agent — so «what is this screen?» and «why is this disabled?» are answerable while
nothing is ever filled or pressed. «Show me where that is» rides the same read gate: scrolling to a
place changes nothing.
On a shared or sensitive screen
Three markers, in order of how much they hide: data-sa-actions="off" (describe, never act),
data-sa-read withheld (state only), data-sa-private (invisible). A host can also switch page
actions off for one page load with Shukai.setPageActions(false).