startSystemMove/startSystemResize causing mouse events to be lost on X11(MATE)

This seem to be the same as https://bugreports.qt.io/browse/QTBUG-68501.

startSystemMove/startSystemResize were private APIs at the time of the report and looks like this was hacked on QSizeGrip side instead. But now they are public APIs and the bug still exists. Calling startSystemMove or startSystemResize causes mouse events to be handled really weird in the entire app. Some widgets don't get MouseMove events, other getting, but QWidget::isAncestorOf returns true even if the widget is not a child of that another widget. The most annoying thing is if you have startSystemMove being called on mouseMoveEvent (in order to allow maximizing by double click on a custom titlebar), Qt calls it as soon as moving was ended (app enters into an endless moving state). I tried to add a check for QMouseEvent::buttons into mouseMoveEvent and don't call startSystemMove if it is Qt::NoButton: it helps in most cases, but not in all, unfortuantely . As a result of this, the behavior (endless moving state) became randomly and happens only at certain conditions, like snapping to screen edges (i guess that's because the cursor is out of window on mouse button release and Qt doesn't understand that the button was released even in MouseMove event).

gtk applications don't have this behavior even though they all using _NET_WM_MOVERESIZE, so I checked what they doing and found that they have a way how to determine when move/resize is done and doing some stuff in order to not to have this buggy behavior:

https://gitlab.gnome.org/GNOME/gtk/-/blob/master/gdk/x11/gdkdisplay-x11.c#L971-977

https://gitlab.gnome.org/GNOME/gtk/-/blob/master/gdk/x11/gdksurface-x11.c#L4335

https://gitlab.gnome.org/GNOME/gtk/-/blob/master/gdk/x11/gdksurface-x11.c#L4215-4219

https://gitlab.gnome.org/GNOME/gtk/-/blob/master/gdk/x11/gdksurface-x11.c#L3876-3887