Environment:
- OpenSnitch GUI version: 1.8.0
- OS: Nobara Linux 44 (KDE Plasma, Wayland)
- Kernel: 7.2.0-202.nobara.fc44.x86_64
- Python: 3.14.7
- Qt: qt6-qtbase 6.11.1
- Display setup: 2 monitors with mismatched resolution/refresh rate — Monitor 1: 2560x1440 @ 180Hz, Monitor 2: 1680x1050 @ 60Hz
To Reproduce:
I wasn't able to trigger this on-demand with a specific sequence of actions — it occurred intermittently during normal use, including:
- Shortly after boot, when a connection popup fired during/just after network setup
- After ~3 hours of the machine sitting completely idle (no interaction), with a popup apparently triggered by a background process
- During active use, though I couldn't isolate a specific action that caused it
My setup uses two monitors with mismatched resolution and refresh rate (2560x1440 @ 180Hz + 1680x1050 @ 60Hz), and my best guess (unconfirmed) is that the crash depends on where the mouse cursor happens to be — specifically on the second, lower-resolution monitor — at the exact moment a popup is shown, since that's the only variable in move_popup() that could make virtualSiblingAt() return None. I don't have a reliable way to force the cursor into the exact failing position, so I can't offer a guaranteed repro — sorry.
Post error logs:
Traceback (most recent call last):
File "/usr/lib/python3.14/site-packages/opensnitch/dialogs/prompt/__init__.py", line 181, in showEvent
self.move_popup()
File "/usr/lib/python3.14/site-packages/opensnitch/dialogs/prompt/__init__.py", line 193, in move_popup
point = self.screen().virtualSiblingAt(QtGui.QCursor.pos()).availableGeometry()
AttributeError: 'NoneType' object has no attribute 'availableGeometry'
Expected behavior (optional):
The popup should display normally without crashing the application.
Additional context:
Root cause & suggested fix
In opensnitch/dialogs/prompt/__init__.py, move_popup():
def move_popup(self):
popup_pos = self._cfg.getInt(self._cfg.DEFAULT_POPUP_POSITION)
point = self.screen().availableGeometry()
point = self.screen().virtualSiblingAt(QtGui.QCursor.pos()).availableGeometry()The first line computes a safe fallback, but its result is immediately discarded by the next line, which calls .availableGeometry() directly on the return value of virtualSiblingAt() without a None check. Per Qt docs, virtualSiblingAt() can return None if no sibling screen contains the given point.
Suggested fix:
def move_popup(self):
popup_pos = self._cfg.getInt(self._cfg.DEFAULT_POPUP_POSITION)
point = self.screen().availableGeometry()
cursor_screen = self.screen().virtualSiblingAt(QtGui.QCursor.pos())
if cursor_screen is not None:
point = cursor_screen.availableGeometry()I've applied this fix locally and confirmed the crash no longer occurs after 4+ hours of normal use (previously crashing multiple times per day, including at boot and during idle periods).
Environment:
To Reproduce:
I wasn't able to trigger this on-demand with a specific sequence of actions — it occurred intermittently during normal use, including:
My setup uses two monitors with mismatched resolution and refresh rate (2560x1440 @ 180Hz + 1680x1050 @ 60Hz), and my best guess (unconfirmed) is that the crash depends on where the mouse cursor happens to be — specifically on the second, lower-resolution monitor — at the exact moment a popup is shown, since that's the only variable in
move_popup()that could makevirtualSiblingAt()returnNone. I don't have a reliable way to force the cursor into the exact failing position, so I can't offer a guaranteed repro — sorry.Post error logs:
Traceback (most recent call last):
Expected behavior (optional):
The popup should display normally without crashing the application.
Additional context:
Root cause & suggested fix
In
opensnitch/dialogs/prompt/__init__.py,move_popup():The first line computes a safe fallback, but its result is immediately discarded by the next line, which calls
.availableGeometry()directly on the return value ofvirtualSiblingAt()without a None check. Per Qt docs,virtualSiblingAt()can returnNoneif no sibling screen contains the given point.Suggested fix:
I've applied this fix locally and confirmed the crash no longer occurs after 4+ hours of normal use (previously crashing multiple times per day, including at boot and during idle periods).