Feedback

Where the button lives

Every page in ResearchOS carries a FeedbackButton in the bottom toolbar (or the corresponding floating cluster on dashboards). Click it and the FeedbackModal mounts. The button is always available because every surface in the app is a fair target for feedback.

The three feedback types

Pick a type at the top of the modal. The modal remembers your last-used type across sessions, so the choice you make most is the one already selected next time (an error-triggered open is the exception, it locks to Bug so you see the crash context you came to report).

• Bug. Something is broken, like a crash, a wrong number, or a misrendering. The modal auto-attaches the current route, the browser/OS string, and any recent uncaught error details so the report has enough context for a fix.
• Feature request. A new capability you wish existed. The modal walks a lighter template (what you want, why) and routes to the enhancement label on GitHub.
• General feedback. Anything that does not fit the first two, like a comment on UX, a typo, or a confused-by-naming note. Routes to the feedback label.

Auto-capture, no auto-submit

On submit, the modal does not POST to a server. It builds a GitHub issue URL with the title, body, and label pre-filled in the query string, then opens that URL in a new tab. You see the body GitHub is about to create, you can edit any of it, and the issue does not exist until you click Submit on the GitHub side. A few things follow from that.

• Nothing on your machine moves until you intentionally submit.
• You can sanitize anything that landed in the auto-attached error details before posting.
• The full report shape is determined by feedback.yml in the repo, so the GitHub side renders a templated form rather than a raw markdown body.
• If you would rather not open a new tab, a Copy Link button puts the same pre-filled issue URL on your clipboard so you can open it yourself.

Attaching screenshots

Every feedback type lets you attach screenshots, by dropping them on the modal, pasting from the clipboard, or clicking to pick files. The images stay in memory and never leave your machine on their own. A GitHub new-issue URL is text only, so the images cannot ride along with the rest of the report. Instead, when you submit with screenshots attached, the modal opens the issue tab and then shows a short last step that keeps your thumbnails handy. The clipboard holds one image at a time, so you copy each thumbnail and paste it into the GitHub description under the Screenshots heading, one at a time.

The BugStomp scene

The BugStomp scene (a small BeakerBot moment you might hit after a crash recovery) ends with the same feedback flow. Stomping the bug opens the FeedbackModal pre-set to Bug type and prefilled with a hint from the crash context. It's the same modal as the manual entry point, just with an auto-populated body. If you have reduced motion turned on, the animation is skipped and you get a static aftermath tableau instead.