Screenshot Feedback Widget

A screenshot feedback widget helps a reporter capture a visible UI state, point to the relevant region, and send that artifact with environment context. BugDrop supports full-page, selected-element, and selected-area captures in its manual flow, followed by annotation and redaction review.

Use this guide when: the capture and privacy mechanics are the decision. For the repeatable QA process around the artifact, read Visual Bug Reporting.

Try screenshot capture or open the isolated widget sandbox.

Choose the right screenshot mode

BugDrop provides three configuration modes:

• Optional: the reporter may use full page, element, or area capture, annotate or redact it, or skip the screenshot.
• Required: the reporter must add a screenshot through the manual capture and review flow.
• Automatic: BugDrop attempts a full-page screenshot after form submission without showing the manual picker or redaction review.

Optional is the safest default for a pilot because it lets the reporter inspect the image and continue without one. Required is useful when visual evidence is essential and the page is suitable for capture. Automatic reduces interaction but should be limited to pages where sensitive regions are stable, marked, and supported by the DOM capture path.

What capture does and does not prove

A screenshot is strong evidence for clipped text, overlap, missing content, spacing, colors, or an unexpected responsive state. It is weak evidence for timing, intermittent interaction, network failures, and multi-step behavior. Ask reporters to include expected behavior and reproduction steps when a still image cannot tell the whole story.

BugDrop adds URL, browser, OS, language, and viewport fields to the issue. These fields help reproduce the environment, but they do not identify the root cause automatically.

Full page, area, or element

Use full page when the relationship between distant sections matters. Use selected area when the reporter wants to crop around a compact region. Use selected element when one control or component is the clearest target; BugDrop can include selector metadata and a visible border for that selection.

Selected-element context is configurable. Increasing surrounding context can help a developer understand nearby layout, but it also creates a larger artifact and may expose more content. Keep the captured region as small as the report allows.

Annotation, redaction, and masking

Manual capture lets the reporter draw, add an arrow, and redact visible regions before submitting. Redactions are embedded in the uploaded image. Site owners can also mark DOM elements with data-bugdrop-mask, data-bugdrop-redact, or another supported attribute so BugDrop covers measured boxes in supported DOM-rendered captures.

Masking has important limits:

• It does not discover unmarked secrets or inspect pixels inside media and embedded content.
• Native viewport fallback cannot apply element masks.
• A layout change during capture can make a measured mask stale.
• Automatic mode does not show the reporter a review step.

Password inputs and supported credit-card autocomplete fields are masked automatically on supported DOM-rendered paths, but teams should still test their exact page. If sensitive pixels cannot be enclosed reliably, disable screenshots there.

A useful visual-report example

A reviewer notices that a modal footer is cut off at a particular viewport. They choose the modal element, add an arrow to the hidden action, and describe the expected footer behavior. The issue contains the selected visual context and environment details. A developer can reproduce the viewport and inspect the component, while the screenshot remains evidence of the report rather than a substitute for verification.

Test before collecting real reports

On a staging page, exercise every enabled capture path. Confirm the final PNG includes the intended area, annotations remain visible, marked private content is fully covered, unmarked sensitive content is absent, and the screenshot branch is excluded from CI. Also test failure and skip paths so feedback can still be submitted when capture is unavailable.

Run the portable Screenshot Privacy Checklist against the final image and destination, then read screenshot configuration, masking limits, and installation before launch.