Browser plugin: add a step that saves the page DOM to a file in the artifacts directory #96
Copy link
Copy link
Closed
bddkit/bddkit-browser
#3Description
Problem
There is no way to get the page's DOM out of a scenario. I execute the script returns a string into <<script_result>>, but nothing writes a variable to a file, so the only option is printing it to the log, where it is truncated. Writing a selector for an unfamiliar page means a full run per guess.
Proposal
Add two steps, kind action, same shape as I dump the browser console:
I dump the DOM– writes the serialized current document as HTML into the artifacts directory.I dump the DOM of "<selector>"– same for one element's outerHTML (CSS,xpath=ortext=, like the other selectors).
Behaviour:
- Never waits (like steps 26–28); use an eventual assertion to arm it.
- The file name does not collide with a previous dump in the same scenario (
dom-<n>.html). on_failuregains adomvalue (off by default); the failure diagnostic carries the file path.
Implementation notes
- Add
GET /session/{id}/sourcetowebdriver.rs; the element form usesexecutewitharguments[0].outerHTML. - The source endpoint does not include shadow roots or iframe contents. Document this; walking them can be a follow-up.
Open questions
- Masking: hidden fields, tokens and input values end up in the file. Dumps should go through the same masking as other output.
- Screenshots have the same overwrite problem today (
screenshot.png).
Note
The steps belong to the browser plugin (bddkit/bddkit-browser, src/steps.rs); filed here for tracking.
Generated by Claude Code
Metadata
Metadata
Assignees
Labels
No labels
Activity
sergeym commentedon Oct 9, 2026
Implemented in bddkit/bddkit-browser#3. Decisions taken:
dom-<n>.htmland, as the issue noted,screenshot-<n>.pngtoo.ncounts from 1 per kind, per scenario, and starts over at the next scenario. The host already gives every step its ownartifacts_dir, so nothing was being overwritten; the number records the order within a scenario, it does not prevent a collision. Both DOM steps share one counter.I dump the DOM of: looks once and fails at once on a missing element (fatal; an action cannot answernot_yet). Arm it with an eventual assertion about the element, like steps 26–28.on_failure: dom: off by default; the failure dump gets aDOM (html)entry with the file path, not the HTML itself.domis opt-in. Masking would need a host-level mechanism first. Left open.outerHTML); documented, walking them is a follow-up.CIis set and the browser orbddkitis missing, so the examples cannot pass unrun.feat: add I dump the DOM and on_failure dom (bddkit/bddkit#96)
feat: number screenshot and DOM dump file names within a scenario (bd…
docs: example a second numbered dump and on_failure dom (bddkit/bddki…