From f52c44821a9287786c91427af1df32f22f5f0c2d Mon Sep 17 00:00:00 2001 From: Richard Tang Date: Fri, 17 Apr 2026 12:16:13 -0700 Subject: [PATCH] feat: partially validation after typing --- .../skills/_default_skills/browser-automation/SKILL.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/core/framework/skills/_default_skills/browser-automation/SKILL.md b/core/framework/skills/_default_skills/browser-automation/SKILL.md index ffc78e89..041f64c4 100644 --- a/core/framework/skills/_default_skills/browser-automation/SKILL.md +++ b/core/framework/skills/_default_skills/browser-automation/SKILL.md @@ -53,7 +53,7 @@ Whereas `wait_for_selector`, `browser_click(selector=...)`, `browser_type(select 1. Call `browser_click_coordinate(x, y)` to click the target element. 2. Check the `focused_element` field in the response — it tells you what actually received focus (tag, id, role, contenteditable, rect). -3. If the focused element is editable, call `browser_type_focused(text="...")` to insert text. use tools to verify the text took effect. +3. If the focused element is editable, call `browser_type_focused(text="...")` to insert text. Use tools to verify the text took effect — prefer checking the underlying `.value` / `innerText` via `browser_evaluate` or confirming the submit button enabled. A screenshot alone can mislead: narrow input boxes visually clip long text, so only a portion may appear on screen even though the full string was accepted. 4. If it is NOT editable, your click landed on the wrong thing — refine coordinates and retry. Do NOT reach for `browser_evaluate` + `execCommand('insertText')` or shadow-root traversals. The problem is the click target, not the typing method. `browser_click` (selector-based) also returns `focused_element`, so the same check works whether you clicked by selector or coordinate. @@ -139,6 +139,8 @@ The symptom is always the same: **you type, the characters appear visually, and 3. **Verify** the submit button is enabled before clicking it. Use `browser_evaluate` to check the button's `disabled` or `aria-disabled` attribute. Do NOT trust that typing worked — always check state. + **Partial visibility is fine.** Small single-line inputs, chat boxes with fixed width, and search fields commonly clip or truncate long text visually — only the tail or head may be shown on screen. Don't treat that as failure. What matters is that the framework accepted the input: the submit button enabled, or `element.value` / `innerText` read via `browser_evaluate` contains the full string. If the visible pixels don't match what you typed but the button is enabled and the underlying value is correct, typing succeeded — proceed. + 4. **Only click send if the button is enabled.** If the button is still disabled, try the recovery dance: click the textarea again, press `End`, press a space, press `Backspace` — this forces React to recompute `hasRealContent`. Then re-check the button state. ### Why `browser_type` uses `Input.insertText` by default