Capturing Browser Failures Without Persisting Form Values

pandaMjm — Thu, 03 Sep 2026 04:41:49 +0000

A screenshot captures the outcome of a browser failure.

It usually does not capture the path that produced it.

By the time a bug reaches another developer, the original browser session is gone. The recipient sees the screenshot, but not necessarily:

the action immediately before the failure
the console error that appeared at the same time
the request that returned HTTP 503
the browser and page involved
whether the captured evidence was complete
whether an attachment changed after the report was created

The obvious response is to record more data.

That creates a second problem: browser sessions contain far more
sensitive information than most bug reports need.

The evidence boundary matters more than the recorder

A browser recorder can observe URLs, form inputs, request headers,
console messages, cookies, DOM state, screenshots, and user actions.

Persisting all of that may produce a detailed replay, but it also creates an artifact that is difficult to inspect, difficult to share, and risky to keep.

For a local bug handoff, I found a smaller boundary more useful:

a value-free action trail
relevant console errors
failed requests and HTTP error responses
browser identity
limited page state
a screenshot
an explicit capture receipt

The goal is not to recreate everything the user saw. It is to preserve the smallest useful action-to-failure chain.

For example:

click button #7
  -> HTTP 503 GET /api/http-error
  -> console error: fixture:request-failed
input input #4 (length=14; value never persisted)
submit form

The input action is useful. The value is not.

Recording the character count confirms that an input occurred without
turning the report into a storage location for an email address,
password, token, or other form value.

Redact before persistence

Redaction is strongest when sensitive data never reaches persistent
storage.

That means the capture path should sanitize data before appending it to an event log or report—not after the final report is assembled.

Some practical boundaries include:

remove credentials embedded in URLs
redact sensitive query parameters
redact authorization-like strings
never record typed form values
bound dynamic strings by UTF-8 byte length
visibly mark truncation instead of silently losing data
expose dropped or corrupted evidence as degraded health

The last point is important.

A recorder should not produce a clean-looking report after it failed to write part of the evidence. Missing evidence is itself evidence about the reliability of the capture.

Keep observations separate from conclusions

Suppose a user clicks Save, a request returns HTTP 503, and an error
message appears.

The recorder can safely report:

A click was followed by an HTTP 503 response and a visible error.

It cannot safely report:

The HTTP 503 caused the visible error.

The events are temporally related, but temporal proximity is not proof of root cause.

A durable bug report should make that distinction explicit. Developers and coding agents can investigate the code afterward, but the recorder should not turn correlation into a confident diagnosis.

Make the artifact independently checkable

A report directory is more useful when the recipient can check it
without reopening the application or browser.

A minimal verification layer can check:

the report format and compatible version
safe attachment paths
declared attachment sizes
SHA-256 attachment hashes
capture receipt consistency
whether the browser shutdown result contradicts the report

This does not prove who created the report. It also does not prove that the reported root cause is correct.

It does detect accidental or deliberate attachment changes and
structural inconsistencies.

Those authenticity limits should be part of the output rather than
hidden in documentation.

Why not use a HAR, Playwright trace, or Sentry?

These tools solve adjacent problems.

A HAR file is a good fit when the primary artifact is network traffic.

Playwright is a good fit after a flow is understood well enough to
automate as a repeatable test.

Sentry and similar observability systems are designed to collect
failures across deployed applications and real users.

DevTools and browser MCP tools are strong choices for live
investigation.

The gap I wanted to address was narrower:

A human can reproduce the local browser bug, but it has not been
automated yet, and the evidence needs to survive the browser session.

That is a handoff problem rather than a testing or monitoring problem.

A small implementation of this approach

I implemented these constraints in an MIT-licensed CLI called
BugBaton.

It launches an isolated Chrome profile on a loopback CDP endpoint,
records one manual reproduction, and writes ordinary JSON, Markdown,
and PNG files.

It requires:

Node.js 22 or newer
Chrome, Chromium, or Chrome Canary

It does not require:

an account
a cloud service
a browser extension
an MCP server
runtime npm dependencies
telemetry

The packaged deterministic demo can be run without cloning a repository or providing an existing application:

npm exec --yes --package=bugbaton -- bugbaton demo

The demo only reports success after observing an action, a browser error, and a failed request. Otherwise, it returns an explicit incomplete evidence error.

A saved report can be checked later with:

bugbaton verify REPORT_DIR

The implementation, example report, tests, and design decisions are
available here:
https://github.com/mun-jeong-min/BugBaton

The main question I am still exploring is not how much browser data can be captured.

It is how little data a useful browser failure handoff actually needs.

What would you remove from this evidence boundary, and what would you
still need before trusting the report?

Disclosure: I am the author of BugBaton. I used an AI coding and writing assistant to help edit this article. I reviewed the technical claims, commands, and examples.