fix(cli): surface no-match failures in browse click/fill#2309
Conversation
browse click and browse fill returned { clicked: true } / { filled: true }
and exited 0 even when the selector matched no element, because they run
through act() — which reports a missing element via success:false rather
than throwing. The sibling commands select/upload already error via
deepLocator, so click/fill were inconsistent outliers that silently
reported success on a no-op.
Check the act() result and throw its message when success is false, so a
no-match click/fill exits non-zero like the rest of the element commands.
Adds unit coverage for both the failure (throws) and success paths, and
that a failed fill never presses Enter.
🦋 Changeset detectedLatest commit: aee59f5 The changes in this PR will be included in the next version bump. This PR includes changesets to release 0 packagesWhen changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
This PR is from an external contributor and must be approved by a stagehand team member with write access before CI can run. |
There was a problem hiding this comment.
No issues found across 3 files
Confidence score: 5/5
- Automated review surfaced no issues in the provided summaries.
- No files require special attention.
Architecture diagram
sequenceDiagram
participant Client as CLI User
participant Handler as Elements Handler (elements.ts)
participant Manager as Driver Manager
participant Stagehand as Stagehand (act)
participant Page as Active Page
Client->>Handler: click(selector) or fill(selector, value, pressEnter?)
Handler->>Manager: stagehandInstance()
Manager-->>Handler: stagehand
Handler->>Stagehand: act({action: "click"|"fill", selector, ...})
Stagehand-->>Handler: { success: false, message: "Could not find..." }
alt success == false (NEW)
Handler->>Handler: throw new Error(result.message)
Handler-->>Client: Non-zero exit + error message
else success == true
opt fill with pressEnter
Handler->>Page: keyPress("Enter")
end
Handler-->>Client: { clicked: true } / { filled: true, pressedEnter }
end
why
browse clickandbrowse fillreport success on a selector that matches nothing. Reproduced onbrowse@0.9.1against a real page:Every other element command errors correctly on the same no-match selector:
click/fillare the only outliers. They run throughstagehand.act(), which reports a missing element viasuccess:falserather than throwing (actHandler.ts), and the handlers discard that result — so a script or agent driving the CLI proceeds on a false premise.what changed
packages/cli/src/lib/driver/commands/elements.ts—clickandfillnow check theact()result andthrow new Error(result.message)whensuccessis false, so they exit non-zero and print the same "Could not find an element" error as their siblings. A failedfillno longer presses Enter afterward.test plan
Adds
tests/element-command-failures.test.ts(5 cases, mock manager per the existingdriver-commands.test.tspattern): click/fill throw onsuccess:false, resolve on success, and a failed fill never presses Enter. Adjacent suites (driver-commands,driver-foundation) still green;tsc -p tsconfig.jsonclean.The pre-fix behavior above was reproduced live; the fix is covered by the unit tests (a full end-to-end run needs a driver session).
Summary by cubic
Fixes the
browseCLI sobrowse clickandbrowse fillfail with a clear error and non-zero exit when the selector matches no element, aligning with other element commands.act()error message whensuccess:falseinstead of reporting success.fillno longer presses Enter after a failed action.Written for commit aee59f5. Summary will update on new commits.