Website feedback

Website Feedback Tool for Developers

Capture website feedback on the page, save the report in ContextCapture, review screenshot and browser context, and optionally send it to GitHub or AppHandoff.

Capture website feedback where the problem appears

ContextCapture's website feedback widget lets a reporter describe a page problem where it occurs, review the available screenshot and browser context, and send a report. ContextCapture saves that report in its inbox first. A site may choose GitHub or AppHandoff as an optional downstream ticket destination; the two fictional workflows below show what a developer can review next.

Choose the right feedback path

For a visible bug, capture the affected page, pin the control if it helps, and describe one action, the expected result, and what actually happened. For an idea or missing context, explain the desired change and why it matters without inventing a failure. Both reports need a reviewer to distinguish observed behavior from a proposed solution.

Visible bug: include the tested starting state and a repeatable action; review the screenshot for the state it actually shows.
Idea or unclear behavior: say what is wanted or unknown, then ask the site team to clarify before treating it as a confirmed defect.
Use test data and remove private page content before sharing evidence outside the team.

1. Set up the site and optional destination

Install the widget on the site using the script tag in the docs. Reports save to the ContextCapture inbox first. If your team also wants tickets, select one downstream destination for the site: GitHub or AppHandoff. A GitHub connection selects a repository for issue delivery, not widget sign-in.

Try a test page and a test destination before inviting clients or QA.
If using GitHub, confirm the site's connection, repository, and ticket destination in settings.
Without a ticket destination, review the saved report in the ContextCapture inbox and create a ticket manually if needed.

2. Capture the reporter's observation

The reporter opens the widget on the affected page, signs in to ContextCapture, and selects Capture. They can pin a relevant element, describe the action and result, inspect the screenshot and evidence details, then send. Sign-in offers Continue with contextcapture.ai and an email-code fallback; GitHub is not the login provider.

Describe a reproducible action and the expected and actual result in the reporter's own words.
Check the screenshot before sending; if it cannot attach, the widget warns and sends the report without it.
Review URLs, visible page content, and console details for private data before sharing an issue with a wider team.

3. Confirm delivery and triage

After a successful Send, keep the report reference if the receipt shows one. The receipt describes what was saved or delivered and shows a GitHub link only after delivery. The site team can inspect the saved report in its inbox when no tracker link appears.

Keep the reference or open the ContextCapture report if the receipt provides its link; a missing GitHub link does not mean the capture was lost.
If no tracker link appears, review the saved report, then check the chosen destination or create a manual ticket from reviewed facts.
Check the reported action, expected and actual result, environment, and evidence before claiming a root cause.

If the receipt and tracker do not match

Treat the Send receipt as the first handoff record. If it confirms a saved report but shows no tracker link, use the report reference to find that capture in the ContextCapture inbox. Then check the site's chosen destination and delivery status before creating another ticket. A missing tracker link does not tell you whether the underlying page bug repeated or why delivery did not occur.

Record the report reference, send time, site, and what the receipt actually displayed.
Review the saved report and destination setting before manual ticket creation so the team can avoid two tickets for one capture.
If no report reference is available, preserve the visible receipt and ask the site team to locate the capture; do not invent a ticket URL.

What the evidence can and cannot say

A page screenshot, selected element context, browser and viewport details, available console entries, and the reporter's note can give a developer a starting point. The widget does not capture or attach a full HAR file or diagnose the cause. Missing screenshots, absent console messages, and intermittent failures still need human follow-up.

A console message is an observation, not proof of the cause.
For a network investigation, collect and review a separate HAR file before sharing it.
Do not put credentials, personal data, or private client URLs in a public GitHub issue.

Prepare your next report

Screenshot annotator Bug report generator Reproduction-steps guide Console-log guide HAR analyzer Installation docs See a sample report Start your 14-day free trial

Updated October 10, 2026. Originally published October 8, 2026.

These two workflows and issue bodies are fictional examples of a reviewable handoff. They do not show a customer capture or a delivered ticket.

Builder example: checkout button stops responding

A tester on a staging checkout page clicks Place order and sees no confirmation. The developer needs the exact action, environment, and evidence before investigating.

Reporter steps

Open the staging checkout page and sign in to the widget when prompted.
Select Capture, pin Place order, and write: ‘Clicking Place order leaves me on checkout with no confirmation.’
Inspect the screenshot and evidence details, then send the report.

Developer handoff

Open the saved report in ContextCapture; if GitHub delivery succeeded, follow its issue link.
Compare the screenshot and console entry with the checkout code, then reproduce in the reported browser.
Ask the tester for missing steps if the failure is intermittent; do not infer the cause from the console entry alone.

[Illustrative] Place order has no visible result on staging checkout

Reporter: QA tester (fictional)
Page: https://staging.example.test/checkout (fictional)
Steps: Add an item, open checkout, click Place order.
Expected: Confirmation or a visible validation message.
Actual: The page remains on checkout with no visible response.
Evidence to inspect: ContextCapture screenshot of the button and page state; selected button context; browser and viewport; recent console entries. Example console observation: ‘TypeError: Cannot read properties of undefined’ (illustrative, not a diagnosis).
Next step: Reproduce in the recorded browser, inspect the checkout submit path, and ask for any missing data. No HAR is attached.

Start your 14-day free trial

Agency example: client cannot submit a contact form

A client reviewing a campaign site says the contact form looks stuck. The agency needs a clear report that can move from the client to the developer without exposing client data.

Reporter steps

Ask the client to open the affected page, sign in to the widget, and reproduce the problem with test data.
Select Capture, pin Send message, and describe the visible result: ‘The button spins, then the form stays open.’
Review the screenshot for names, email addresses, and other private fields before sending; remove sensitive test content or use a clean test submission.

Developer handoff

The agency checks the saved report and confirms which browser, page, and form action were involved.
If the site is configured for GitHub, follow the delivered issue link; otherwise make a manual issue from the reviewed facts.
The developer reproduces with test data, records what the investigation finds, and asks the client to retest after a confirmed change.

[Illustrative] Contact form stays open after Send message

Reporter: client reviewer (fictional)
Page: https://campaign.example.test/contact (fictional)
Steps: Fill the form with test data and click Send message.
Expected: A success message or a clear validation error.
Actual: The button spins and the form remains open.
Evidence to inspect: Reviewed screenshot, selected Send message element, browser and viewport, and available console entries. No client-submitted personal data is copied into this issue.
Next step: Reproduce with test data, inspect the form request in the developer's own tools, and ask the client to retest after a fix. No HAR is attached.

Start your 14-day free trial

Capture the next report with ContextCapture

Start a 14-day free trial. The beta plan is $7.99 per month for unlimited projects and reports, with up to 5 team members.

Start your 14-day free trial

Website feedback

Website Feedback Tool for Developers

Capture website feedback on the page, save the report in ContextCapture, review screenshot and browser context, and optionally send it to GitHub or AppHandoff.

Capture website feedback where the problem appears

Choose the right feedback path

Visible bug: include the tested starting state and a repeatable action; review the screenshot for the state it actually shows.
Idea or unclear behavior: say what is wanted or unknown, then ask the site team to clarify before treating it as a confirmed defect.
Use test data and remove private page content before sharing evidence outside the team.

1. Set up the site and optional destination

Try a test page and a test destination before inviting clients or QA.
If using GitHub, confirm the site's connection, repository, and ticket destination in settings.
Without a ticket destination, review the saved report in the ContextCapture inbox and create a ticket manually if needed.

2. Capture the reporter's observation

Describe a reproducible action and the expected and actual result in the reporter's own words.
Check the screenshot before sending; if it cannot attach, the widget warns and sends the report without it.
Review URLs, visible page content, and console details for private data before sharing an issue with a wider team.

3. Confirm delivery and triage

Keep the reference or open the ContextCapture report if the receipt provides its link; a missing GitHub link does not mean the capture was lost.
If no tracker link appears, review the saved report, then check the chosen destination or create a manual ticket from reviewed facts.
Check the reported action, expected and actual result, environment, and evidence before claiming a root cause.

If the receipt and tracker do not match

Record the report reference, send time, site, and what the receipt actually displayed.
Review the saved report and destination setting before manual ticket creation so the team can avoid two tickets for one capture.
If no report reference is available, preserve the visible receipt and ask the site team to locate the capture; do not invent a ticket URL.

What the evidence can and cannot say

A console message is an observation, not proof of the cause.
For a network investigation, collect and review a separate HAR file before sharing it.
Do not put credentials, personal data, or private client URLs in a public GitHub issue.

Prepare your next report

Screenshot annotator Bug report generator Reproduction-steps guide Console-log guide HAR analyzer Installation docs See a sample report Start your 14-day free trial

Updated October 10, 2026. Originally published October 8, 2026.

These two workflows and issue bodies are fictional examples of a reviewable handoff. They do not show a customer capture or a delivered ticket.

Builder example: checkout button stops responding

A tester on a staging checkout page clicks Place order and sees no confirmation. The developer needs the exact action, environment, and evidence before investigating.

Reporter steps

Open the staging checkout page and sign in to the widget when prompted.
Select Capture, pin Place order, and write: ‘Clicking Place order leaves me on checkout with no confirmation.’
Inspect the screenshot and evidence details, then send the report.

Developer handoff

Open the saved report in ContextCapture; if GitHub delivery succeeded, follow its issue link.
Compare the screenshot and console entry with the checkout code, then reproduce in the reported browser.
Ask the tester for missing steps if the failure is intermittent; do not infer the cause from the console entry alone.

[Illustrative] Place order has no visible result on staging checkout

Reporter: QA tester (fictional)
Page: https://staging.example.test/checkout (fictional)
Steps: Add an item, open checkout, click Place order.
Expected: Confirmation or a visible validation message.
Actual: The page remains on checkout with no visible response.
Evidence to inspect: ContextCapture screenshot of the button and page state; selected button context; browser and viewport; recent console entries. Example console observation: ‘TypeError: Cannot read properties of undefined’ (illustrative, not a diagnosis).
Next step: Reproduce in the recorded browser, inspect the checkout submit path, and ask for any missing data. No HAR is attached.

Start your 14-day free trial

Agency example: client cannot submit a contact form

A client reviewing a campaign site says the contact form looks stuck. The agency needs a clear report that can move from the client to the developer without exposing client data.

Reporter steps

Ask the client to open the affected page, sign in to the widget, and reproduce the problem with test data.
Select Capture, pin Send message, and describe the visible result: ‘The button spins, then the form stays open.’
Review the screenshot for names, email addresses, and other private fields before sending; remove sensitive test content or use a clean test submission.

Developer handoff

The agency checks the saved report and confirms which browser, page, and form action were involved.
If the site is configured for GitHub, follow the delivered issue link; otherwise make a manual issue from the reviewed facts.
The developer reproduces with test data, records what the investigation finds, and asks the client to retest after a confirmed change.

[Illustrative] Contact form stays open after Send message

Reporter: client reviewer (fictional)
Page: https://campaign.example.test/contact (fictional)
Steps: Fill the form with test data and click Send message.
Expected: A success message or a clear validation error.
Actual: The button spins and the form remains open.
Evidence to inspect: Reviewed screenshot, selected Send message element, browser and viewport, and available console entries. No client-submitted personal data is copied into this issue.
Next step: Reproduce with test data, inspect the form request in the developer's own tools, and ask the client to retest after a fix. No HAR is attached.

Start your 14-day free trial

Capture the next report with ContextCapture

Start a 14-day free trial. The beta plan is $7.99 per month for unlimited projects and reports, with up to 5 team members.

Start your 14-day free trial