#55 Frameless window's global resize event filter can freeze all mouse input

[Anonymous]

Originally created by: musqz
Originally owned by: Sanjaya-Danushka

Summary

The frameless main window installs a global, application-wide mouse event filter for edge-resize handling. If the resize gesture doesn't hand off cleanly to the window manager, the filter's "resize in progress" flag can get stuck true, which then silently swallows every mouse press/move event in the whole window — not just near the edge — until the app is restarted.

Where

neoarch/frontend/main_window.py, eventFilter() (around line 307-339):

def eventFilter(self, obj, event):
    ...
    if etype == QEvent.Type.MouseMove or etype == QEvent.Type.MouseButtonPress:
        ...
        if self._resize_active:
            return True   # <- swallows ALL mouse press/move, app-wide, while stuck
        ...
        elif etype == QEvent.Type.MouseButtonPress:
            if edge is not None and event.button() == Qt.MouseButton.LeftButton:
                handle = self.windowHandle()
                if handle is not None:
                    self._resize_active = True
                    handle.startSystemResize(edge)
                    return True
    return super().eventFilter(obj, event)

_resize_active is only cleared on a later MouseButtonRelease or Resize event (lines ~309-313). QWindow.startSystemResize() is a hand-off to the compositor/WM — on some window managers it can fail to start the interactive resize or fail to send back a release/resize event, in which case _resize_active never resets and the filter keeps returning True for every subsequent mouse press/move anywhere in the window.

Observed symptoms (matches this mechanism, not yet confirmed as the cause)

Reported on Mabox Linux (Openbox-based by default). After installing a package, two unrelated controls stopped responding to clicks at the same time:

• The console/log panel accepted no input (couldn't select/interact with it).
• The package detail panel's "Check for Updates" button did not visibly react to clicks.

Two independent widgets going dead simultaneously points at something app-wide rather than two separate per-widget bugs — this event filter is the only application-wide input gate in the codebase, which is why I suspect it. I have not reproduced it under a debugger/log to confirm _resize_active was actually stuck, so treat this as a lead rather than a confirmed root cause.

Suggested mitigations

• Add a watchdog: if no Resize/MouseButtonRelease arrives within ~1-2s of setting _resize_active = True, clear it defensively.
• Also clear _resize_active on QEvent.Type.WindowDeactivate / ApplicationStateChange, so alt-tabbing away mid-resize can't leave it stuck.
• Consider logging when _resize_active is cleared vs. how long it was held, to make this reproducible if it recurs.

Happy to send a PR for the watchdog if that approach sounds right — wanted to flag the mechanism first since I couldn't reliably reproduce it on demand.

[Anonymous]

Originally posted by: Sanjaya-Danushka

Yes, I see the problem. I will fix it within 24 hours.

[Anonymous]

• assigned_to: Sanjaya-Danushka