The case I worry about is that of the mouse down and up events. A problem can occur if another window is activated between these two events, especially during a drag operation, meaning that the mouse-up event is received by that other window, so the window to receive the mouse-down event may never fully terminate its handling.

This case is rare enough, but potentially destructive to the UI. Do you know if this can happen in Qt when not using manual grab ?

My understanding is that grab/release in Qt are frowned upon

Somewhat, albeit sometimes they are needed, hence the mouse grabbing is exposed through the public API.

the underlying mouse logic seems solid enough so they are not really required

Yes, most of the time.

I'm not sure that a simple test program could duplicate this condition.

Well, the thing is this:
Even if you post this as a bugreport, you'd want to have some collaboration for someone to pick it up. What I mean is that if you don't provide any means of reproduction (i.e. a test case application) and your description is vague or the bug is very complex/hard to reproduce it may stay in the tracker for a long, long time ... attaching screenshots also might help the developers to triage and ultimately fix the bug.

Kind regards.

It might be that the close button is essential and its handler should release the grab.

@kshegunov

I see I was right not to post a bug report, since the case is too vague.

My understanding is that grab/release in Qt are frowned upon, and my (limited) experience now is that the underlying mouse logic seems solid enough so they are not really required.

All I can say is that the application, while using Windows API, did release correctly all its grabs. However, under Qt the same application managed to place itself in a situation where the last release did not work and a virtual grab remained in effect. I'm not sure that a simple test program could duplicate this condition.

I theorize that when the X button is pressed, the window becomes invisible and the releaseMouse is ignored

Doubtful. You have to match the grabs with releases, possibly you have a codepath somewhere that doesn't go through the release. Also if I recall correctly, you need to call release the exact number of times you call grab.

@mrjj

If you new a Widget, let it grab and then delete it, the mouse is restored.

This is platform specific and ultimately will depend on the window manager. Usually the window manager will release the grab when the receiving native surface handle is destroyed.

Hide does not release it.

Nor should it. Grabbing the mouse is quite an exclusive operation.

hi , just made small test.

If you new a Widget, let it grab and then delete it, the mouse is restored.
So seems that delete will release.

so I guess you hide a window while it has grab?
Ill test that in a moment.

update:
Hide does not release it.

Agreed, but in this one case there might be a gotcha.

the doc states

Warning: Bugs in mouse-grabbing applications very often lock the terminal. Use this function with extreme caution, and consider using the -nograb command line option while debugging.

so I would not count on auto clean up.