Add progress/result window to the Bug Report flow with a GitHub issue shortcut

[Niels Laute (niels9001)]

Summary of the Pull Request

Adds a small, native progress/result window to the Bug Report flow so users get feedback while the report is generated and a one-click path to file a GitHub issue.

Previously, triggering "Report bug" (from the tray menu or Settings → General) ran PowerToys.BugReportTool.exe hidden for ~30 seconds with no feedback at all, then popped a plain message box. Many users then had to manually find the .zip and figure out where to file the issue.

Now the runner shows a lightweight window that:

• Displays an animated "Generating bug report…" state while the tool runs.
• On completion, shows where the .zip was saved (…\Desktop\PowerToysReport_<timestamp>.zip) in a read-only, copyable field.
• Offers Open folder (reveals/selects the .zip in Explorer) and Report on GitHub (opens the prefilled bug_report.yml issue template and reveals the .zip so it can be dragged into the issue).
• Shows a clear error state if the report could not be created.

Note: GitHub has no API/URL to pre-attach a binary to a new issue (attachments only happen via browser drag-drop). So the "Report on GitHub" action does the next best thing: opens the prefilled issue page and highlights the .zip in Explorer for a single drag to attach.

Recording.2026-06-28.140652.mp4

PR Checklist

• Closes: #xxx
• Communication: Lightweight, additive UX on an existing feature; happy to adjust per maintainer feedback.
• Tests: No automated tests (native Win32 window in the runner); validated manually — see below.
• Localization: All end-user-facing strings are added to src/runner/Resources.resx and loaded via GET_RESOURCE_STRING.
• Dev docs: N/A
• New binaries: None — bug_report_dialog.cpp/.h compile into the existing PowerToys.exe (runner). No new WinUI app or DLL, so no signing/WXS/CI changes required.

Detailed Description of the Pull Request / Additional comments

• New files src/runner/bug_report_dialog.{h,cpp} implement the window as plain Win32 (no Common Controls v6 dependency, no managed/WinUI payload), so it works for both entry points since it lives in the runner.
• bug_report.cpp now calls run_bug_report_dialog(...) instead of the silent run + message box. The "running" state (observed by Settings) is cleared as soon as the tool process exits, so the result window can stay open without keeping the Settings button spinning. A guard re-focuses an already-open window instead of starting a second report.
• The window uses the canonical AttachThreadInput foreground recipe so it reliably surfaces even when launched from Settings (a different foreground process), and gets a taskbar button so it stays findable during the ~30s run.
• The output path is discovered by locating the newest PowerToysReport_*.zip in the Desktop folder after the tool exits (the tool names the file internally with a timestamp).
• Strings added: dialog title, generating/hint text, done header/hint, failed text, and button captions.

Validation Steps Performed

• Triggered Report bug from the system tray menu: window appears in the foreground, animates "Generating…", then shows the saved .zip path with working Open folder and Report on GitHub buttons.
• Verified Open folder selects the .zip in Explorer and Report on GitHub opens the prefilled bug_report.yml issue template with the .zip highlighted for drag-and-drop.
• Verified the error state renders correctly (and wraps long localized text) when the tool can't run.
• Built runner (ARM64, Debug) clean; verified end-to-end on a high-DPI display.

[Copilot]

Pull request overview

This PR improves the Runner’s Bug Report experience by adding a lightweight native (Win32) progress/result window around PowerToys.BugReportTool.exe, including shortcuts to reveal the generated .zip and open the GitHub bug-report issue template.

Changes:

• Replaces the previous hidden execution + message box with a native progress/result dialog that stays open after generation.
• Adds dialog UI strings to Runner resources and wires the dialog into the existing Bug Report flow.
• Updates Runner project files to compile the new dialog implementation.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
src/runner/runner.vcxproj.filters	Adds the new dialog .cpp/.h to the project filters.
src/runner/runner.vcxproj	Includes bug_report_dialog.cpp/.h in the Runner build.
src/runner/Resources.resx	Adds localized strings for the progress/result dialog UI.
src/runner/bug_report.cpp	Switches bug report launch to run_bug_report_dialog(...) and uses a callback to clear running state.
src/runner/bug_report_dialog.h	Declares the dialog entry point and callback contract.
src/runner/bug_report_dialog.cpp	Implements the modeless Win32 dialog, tool process execution, and result handling.

[Jiří Polášek (jiripolasek)]

Niels Laute (@niels9001) Nice!

Could an indeterminate progress bar be added while the tool is working? Just to visualize that work is in progress -- with the Close button, it looks like a message box, and some people won't read the fine print before clicking.

[Copilot]

Pull request overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated 3 comments.

Comments suppressed due to low confidence (1)

src/runner/bug_report.cpp:67

• When launch_bug_report() is called while a report is already running, the else-branch notifies observers with isRunning=false. This can incorrectly clear the tray/menu/settings “running” indicators even though the existing bug report is still in progress.

    else
    {
        notify_observers(false);
    }

[Niels Laute (niels9001)]

Jiří Polášek (@jiripolasek) Thanks! I looked into this — a real (marquee) progress bar would mean pulling Common Controls v6 into the runner, and I'd rather not take on that process-wide dependency just for this dialog. The header already animates the "Generating…" dots, so there's a live indicator that work is happening. I'll keep it as-is for now.

[moooyo]

LGTM

[Copilot]

Pull request overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated 1 comment.

Suppressed comments (3)

src/runner/bug_report_dialog.cpp:455

• FindNewestReport can report an old archive as the result of this run. The Bug Report tool logs tar/rename failures without propagating all of them (tools/BugReportTool/BugReportTool/ZipTools/zipfolder.cpp:45-52), so it can exit with code 0 even when no new ZIP was created; this unrestricted lookup then selects any previous PowerToysReport_*.zip and enables both actions for the wrong file. Snapshot the matching files before launch (or require a write time/name created after launch) and only accept a newly created archive.

            const std::wstring zip = (exitCode == 0) ? FindNewestReport(desktop) : std::wstring{};

src/runner/bug_report_dialog.cpp:353

• The runner is PerMonitorV2-aware, but the dialog is permanently laid out using system DPI and the primary monitor work area, with no WM_DPICHANGED relayout. On mixed-DPI systems it opens on the primary monitor rather than beside the invoking Settings window, and moving it to another monitor leaves the custom-sized controls/fonts at the old scale. Initialize from the foreground monitor's work area/DPI and handle WM_DPICHANGED to rebuild or relayout the controls.

    st.dpi = GetDpiForSystem();

src/runner/bug_report_dialog.cpp:484

• This unconditional clear can erase a newer dialog's handle. After this window is destroyed, another launch can observe the stale invalid HWND, create/store its own window, and then this older thread reaches this line and stores nullptr; subsequent launches can create additional dialogs. Clear only if the atomic still contains this window's handle.

    g_dialogWnd.store(nullptr);