Website Feedback Widget

BugDrop is a website feedback widget for teams that want a clear in-page reporting path and developer-ready output in GitHub Issues. This guide owns the broad category question: what the widget does, where it fits, and what a team must decide before installing it.

Use this guide when: you are choosing the general feedback experience for a website or web app. For capture mechanics, use the screenshot feedback guide; for the destination workflow, use the GitHub Issues guide.

Try the reporting flow or inspect it safely in the sandbox.

The job of a website feedback widget

A useful widget reduces work on both sides of a report. The reporter should not have to leave the page, create a GitHub account, or reconstruct basic environment details. The developer should receive more than an unstructured message.

BugDrop places a feedback control on the page. A submission can include the reporter's title and description, a Bug, Feature, or Question category, the current URL, browser, operating system, language, viewport, and an optional screenshot. Name and email fields are off by default and can be enabled when follow-up is appropriate.

The output is a GitHub Issue rather than a separate BugDrop inbox. That is a strong fit when engineering already assigns, labels, discusses, and closes work in GitHub. It is a limitation when product, support, or client teams need a standalone feedback workspace, surveys, voting, session replay, or two-way synchronization with several trackers.

Choose the reporting surface deliberately

Start by deciding where the widget should appear:

• Public marketing or documentation pages: keep the form short and screenshots optional so visitors can skip visual capture.
• Product screens: review masking before enabling screenshots around account, billing, or customer data.
• Preview and staging environments: use a repository and labels that make review feedback easy to separate from production incidents.
• Internal tools: decide whether the hosted public submission path is appropriate or whether a self-hosted authenticated deployment is required.

BugDrop is loaded with a normal synchronous script tag without async or defer and a required data-repo="owner/repo" attribute. Appearance and behavior are configured through data attributes; there is no React provider or framework-specific package.

What a useful first report looks like

Suppose a reviewer sees a navigation button partly covered at a narrow viewport. A useful report says what the reviewer expected, identifies the affected page, and includes the visible state. BugDrop adds the environment fields automatically. If the reporter chooses a screenshot, they can capture the full page, an area, or an element, then annotate or redact before submitting.

The resulting issue gives the developer a concrete starting point without claiming that a screenshot proves the root cause. Reproduction steps, expected behavior, and any account-specific state still belong in the description.

Installation and privacy decisions

Before installation, choose the target repository and install the GitHub App with Issues and Contents permissions. Screenshots are stored on the dedicated bugdrop-screenshots branch, so that branch should be treated as user-generated content and excluded from privileged CI or deploy workflows.

For sensitive pages:

• Mark stable private DOM regions with data-bugdrop-mask or another documented masking attribute.
• Remember that visual masking is not data-loss prevention and cannot discover unmarked secrets.
• Prefer the optional manual screenshot flow when a reporter should review and redact the image.
• Disable screenshots on pages where sensitive pixels cannot be reliably enclosed by DOM boxes.

Read installation, configuration, and screenshot security before enabling the widget on a real site.

Decide with a small pilot

Add BugDrop to one low-risk page, submit a Bug, Feature, and Question report, and inspect the issue body and screenshot branch. Confirm the labels, environment fields, button position, keyboard flow, masking behavior, and repository permissions. Then decide whether to expand the widget to more surfaces.

If the pilot proves the category fit, install the widget. If the team needs a broader managed feedback system, compare website feedback tools before committing.