Bug Description
On macOS, double-clicking a completed video in a torrent's Contents pane can trigger qBittorrent's SIGSEGV crash dialog after the video opens in the default app.
Why This Matters
Why this matters: Opening a downloaded file should not destabilize the qBittorrent GUI.
Trigger / Source
In qBittorrent 5.2.3 (64-bit) on macOS Tahoe 26.5.2 arm64, select a torrent, open Contents, and double-click a video file. The video opens in the associated player, then qBittorrent shows its Crash info dialog.
Verified Facts / Evidence
- qBittorrent's Contents double-click path reaches
TorrentContentWidget::openItem(), which calls Utils::Gui::openPath() (src/gui/torrentcontentwidget.cpp).
- On macOS,
openPath() used QDesktopServices::openUrl() (src/gui/utils.cpp).
- qBittorrent already documents that direct
NSWorkspace use can affect the Qt event loop and avoids it by dispatching Finder-reveal requests in the background (src/gui/macutilities.mm).
Hypothesis / Root Cause
The generic macOS file-opening path lacks the existing asynchronous NSWorkspace workaround. Opening the default application on the Qt event-loop thread leaves a later GUI event vulnerable to a crash.
Expected Behavior
The selected video opens in the associated application and qBittorrent remains stable.
Actual Behavior
The selected video opens, then qBittorrent reports a caught SIGSEGV in its Crash info dialog.
Engineering Plan
Add a macOS MacUtils::openFile() helper that dispatches NSWorkspace::openURL() in the background, and route Utils::Gui::openPath() through it on macOS. Preserve the current Windows and non-macOS code paths.
Regression Tests
- Build the GUI target on macOS with warnings treated as errors.
- Manually open a completed video from Contents and from the Transfer List preview path; confirm the associated app opens and qBittorrent does not display Crash info.
Constraints / Non-goals
Do not change torrent data, associations, the Windows opener, or the Linux/other-platform opener. This is a macOS GUI-thread fix.
Environment / Artifacts
Generated with Codex · gpt-5
Bug Description
On macOS, double-clicking a completed video in a torrent's Contents pane can trigger qBittorrent's SIGSEGV crash dialog after the video opens in the default app.
Why This Matters
Why this matters: Opening a downloaded file should not destabilize the qBittorrent GUI.
Trigger / Source
In qBittorrent 5.2.3 (64-bit) on macOS Tahoe 26.5.2 arm64, select a torrent, open Contents, and double-click a video file. The video opens in the associated player, then qBittorrent shows its Crash info dialog.
Verified Facts / Evidence
TorrentContentWidget::openItem(), which callsUtils::Gui::openPath()(src/gui/torrentcontentwidget.cpp).openPath()usedQDesktopServices::openUrl()(src/gui/utils.cpp).NSWorkspaceuse can affect the Qt event loop and avoids it by dispatching Finder-reveal requests in the background (src/gui/macutilities.mm).Hypothesis / Root Cause
The generic macOS file-opening path lacks the existing asynchronous
NSWorkspaceworkaround. Opening the default application on the Qt event-loop thread leaves a later GUI event vulnerable to a crash.Expected Behavior
The selected video opens in the associated application and qBittorrent remains stable.
Actual Behavior
The selected video opens, then qBittorrent reports a caught SIGSEGV in its Crash info dialog.
Engineering Plan
Add a macOS
MacUtils::openFile()helper that dispatchesNSWorkspace::openURL()in the background, and routeUtils::Gui::openPath()through it on macOS. Preserve the current Windows and non-macOS code paths.Regression Tests
Constraints / Non-goals
Do not change torrent data, associations, the Windows opener, or the Linux/other-platform opener. This is a macOS GUI-thread fix.
Environment / Artifacts
Generated with Codex · gpt-5