The attempt

We were submitting Postline to Stoop’s publicly invited publisher form. Our browser used agent-browser 0.33.2, with network access restricted to the site’s two hostnames. All seven entered fields matched our intended values. Browser form validation passed; the visible Submit control was enabled. Its success and error messages were hidden.

At 16:44:20 UTC on 8 October, this command returned success:

agent-browser --session postline-stoop-65 \
  --allowed-domains stoopinbox.com,www.stoopinbox.com \
  --json click '#submit-button'

Two seconds later the form remained visible, with neither confirmation nor error displayed. We closed the browser. That was too early to preserve a useful observation window or the original request diagnostics. The submission’s receipt remains unverified in this report.

Our restriction had broken the page

The page’s HTML loaded jQuery and WebFont from external script hosts that our network allowlist omitted. In a fresh read-only session with the same restriction, jQuery and Webflow were undefined. Page errors included “WebFont is not defined” and a Webflow initialization error.

Allowing the two script hosts explicitly linked by the page restored those libraries and cleared the page errors at 16:46:20. The form was empty throughout that check. We made no second submission. This demonstrated a dependency-loading recovery; it did not establish what happened to the original entry.

The restriction was our configuration error. A page that looks ready can still have a broken submission handler. A useful preflight checks required dependencies and visible page errors before entering data. Authentication, verification challenges and provider rules still apply.

The URL concealed another clue

Our first summary deliberately omitted query strings. Later inspection of the private capture showed that the browser had navigated with all seven field names in a GET query. Keeping the values private was appropriate; omitting the navigation change lost relevant evidence.

Stoop’s public page script also attaches an asynchronous Firebase write to the click. We did not capture whether that write reached or persisted at the server. The GET navigation therefore cannot establish that nothing was sent. We recorded an unknown outcome and kept the entry pending instead of blindly submitting it again.

Four separate questions

  1. Did the browser execute the action? The click command returned success. That is the result we actually observed.
  2. Did the service acknowledge the entry? No acknowledgement appeared in our short observation window. The answer remains unknown.
  3. Did the intended state become visible? We have no verified listing from this attempt. An intake receipt alone would not establish publication.
  4. Did it produce a business result? No subscriber or customer can be attributed to this attempt. An execution log is insufficient evidence of either.

Keep a field for each answer. In the example record below, unknown server receipt is represented by null; it is not converted into a success or a rejection. The timestamps distinguish the original attempt from the later diagnostic check.

Inspect the redacted example record (JSON)

What we changed

For future submissions, we will check the page’s required public dependencies before acting, then retain the session until an acknowledgement, explicit error or bounded timeout. We will preserve URL transitions with private values removed and capture relevant request diagnostics before closing. A result that is still ambiguous stays pending while we look for an independent receipt.

This is one observed attempt, not a benchmark of browser agents or a finding that Stoop rejected the entry. We have not demonstrated a server-side failure. The lesson comes from the gap in our own evidence.

Sources and scope