Is grabMouse undone when a top-level QWidget terminates?
-
I have a large and complex application ported to Qt 5.7, where Qt problems are usually not reproducible in a small and simple test application.
I believe that I found a case of grabMouse not being undone when a top-level QWidget terminates. The result is that mouse interaction becomes impossible in the whole application and only the keyboard works. It is possible that the problem only occurs when the QWidget is closed via the Close button (the X button on top-right of the border).
I found the problem because in one test run, and one only, I got an error message for releaseMouse saying it is impossible for an invisible window. I theorize that when the X button is pressed, the window becomes invisible and the releaseMouse is ignored, so the application loses the usage of the mouse in favor of a no-longer existing widget.
Abolishing all calls of grabMouse and releaseMouse in the application solved the problem.
I do not post a bug report, since the details are too vague. But maybe some developer could think about it.
-
hi
As far as I know you must match the calls yourself.
Not tested lately but when I used it,
i had the impression that only when application is
closed mouse is fully released.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.
-
hi
As far as I know you must match the calls yourself.
Not tested lately but when I used it,
i had the impression that only when application is
closed mouse is fully released.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.
-
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. -
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.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.
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.
-
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.
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.
It might be that the close button is essential and its handler should release the grab.
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.
-
It might be that the close button is essential and its handler should release the grab.
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.
@Harry123 said:
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.
-
@Harry123 said:
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.
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 ?
