Three capture layers, cheapest first: the sub-route in the URL gives the open tab ('Settings → Team Members'); a DOM scan finds the topmost visible dialog and reads its heading; and components can register explicit context the DOM can't express (which record is selected, which stage a card sits in). The result is a breadcrumb like 'Invoicing → Payments → Record a payment' plus the full URL.
Also called: automatic context · which screen was I on · breadcrumb · captured automatically
- 1The DOM scan matches the app's real modal shapes and picks the topmost by stacking order; ties resolve to the most recently mounted
- 2Inline panels that aren't modals can declare themselves with a single attribute
- 3Explicit context is scoped to the active view, because every view stays mounted after you navigate away — a contact selected hours ago must not 'report' from the pipeline
- 4The widget's own overlay is excluded, so a report never names itself as the dialog you had open
Half of every support conversation used to be working out where the person had been standing — which screen, which tab, which window was open, whose job was on it. The reporter recalls it hours later, badly, and that answer decides whether the problem can be reproduced at all. Every report is stamped with the screen, the open tab, the dialog that was up and a link back to the exact spot, and the reporter types none of it. It reads the screen the way a person does, off the headings, so a window added next month describes itself rather than coming through blank until somebody remembers to label it.
- Bug reports that can't be located because the reporter can't describe where they were
- Round trips of clarifying questions before anyone can start on the fix
See it on your own jobs
Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.
or keep browsing features →