You just hit a broken state on the checkout page. The submit button fires twice, the confirmation flashes and vanishes, and the order lands in your test inbox anyway. Now comes the part QA spends too long on: writing it up so a developer can reproduce it without pinging you three times. Here is the fastest route from what you saw to a report someone can fix, without leaving the browser tab you already have open.
Step 1: Open a capture tab and reproduce the bug once more
Go to start a new review. No install, no extension, no signup prompt blocking you. Trigger the bug again so the broken state is on screen, then click Capture screen. The browser asks which window or screen to share, you pick the tab with the checkout page, and the current frame is drawn to a canvas.
The outcome: you have a still of the exact moment the confirmation flashed, frozen where you can work with it. This is a screenshot, not a recording, so there is no scrubbing back to find the frame that matters. You already caught it.
Step 2: Crop to the part that is actually broken
Drag a rectangle around the double-submit button and the ghost confirmation. Everything outside the rectangle drops away. If the whole viewport is the point, skip the crop and keep the full frame.
Cropping the still is the only image edit here. There are no arrows or boxes to draw, and that is deliberate. A tight crop plus a numbered pin does the same job with less clutter, which is why a cropped still beats an annotated live page for a developer who has to read it later.
Step 3: Drop a pin on the exact element
Add a numbered pin to the submit button. If the bug spans two spots, the double confirmation and the button state, drop a second pin. The pins carry numbers, so you can write "1 fires the POST twice, 2 disappears after 400ms" and the developer reads them in the order you meant. Numbered pins make a developer read steps in order instead of guessing which detail comes first.
Step 4: Dictate the repro steps instead of typing them
Click into the comment on the screenshot and talk. In Chrome or Edge the browser's built-in speech recognition writes it down as you speak: "Add two items, go to checkout, click Place order once. The button fires the request twice and the confirmation banner shows for half a second, then the page redirects to the empty cart." You describe a repro the way you would say it out loud, which is faster and more complete than typing.
Dictation shines for the long ones. A five-step repro with environment notes is a slog to type and quick to say. See when dictation beats typing for a long bug report for the cases where it saves the most time. On Firefox the speech API is not available, so you type instead, and the report is identical either way.
Step 5: Add the environment as a second item
Not every detail needs a screenshot. Add a free-floating comment with no image for the context a developer always asks about: browser version, viewport size, logged-in test account, whether it reproduces on staging or only production. Each captured screenshot and each note is its own item, so the report reads as an ordered list rather than one wall of text.
Step 6: Publish and get the link
Click Publish. The review saves and gets a short public URL at /r/<slug>. Anyone with that link can read the whole thing, no account needed on their end. You can publish with no account at all; the review is kept for 30 days, and if you sign in later with Google or a magic link you claim it permanently.
The outcome: one link that contains the cropped screenshot, the pins, the dictated repro, and the environment notes. Paste it into your tracker, a Slack thread, or the ticket. This is the core of the workflow that QA and test engineers use to close the gap between finding a bug and filing one a developer can act on.
Step 7: Hand the same report to a developer or an agent
The person on the other end decides the format. A developer opens the link and reads it. If they want a paper trail, the same review exports as a PDF or a Word document to attach to the ticket.
If your team hands UI fixes to an AI coding agent, the identical review is available as plain-text markdown at /r/<slug>/markdown. That is the format an agent reads. Paste it into Cursor, Claude Code, or another tool and the agent has the cropped image reference, the pinned element, and your written repro without you rewriting anything. If you want the details of what makes that hold up, read what an agent-readable bug report actually contains.
Step 8: Track comments and mark them resolved
Anyone with the link can post a comment on any individual item, so a developer can ask "which test account?" right on the environment note instead of starting an email thread. As the owner, you mark each comment resolved when it is handled. It is not a bug tracker with workflow states and assignees, and it does not try to be. It is a fast way to resolve review comments without a bug tracker getting in the way.
The whole loop, capture to filed, happens in the tab you already had open. Next bug you find, open a new capture tab before you even reproduce it, and file the report in the same minute you found the problem.