Details
-
Bug
-
Resolution: Done
-
P2: Important
-
5.6, 5.7.1, 5.7, 5.8
-
None
Description
As per the src; Qt assumes that all resize requests will succeed (and in turn, apparently, "proactively" resizes child windows for such requests; it's not clear if this is because of or even related to the noted issue; it may just be how Virtualbox commands Qt5 to behave in this case). This leads to very broken behavior and unusable applications where this assumption is invalid; for a library like Qt, it's never actually valid (as acknowledged by the FIXME: comment).
This has most recently shown its face with the Virtualbox project, exposed by i3 and other window managers, though tiling window managers seem to make use of this protocol more than most. The Virtualbox bug report has some good details; the i3 report has good details on the compounding effects of such an issue.
Original Debian bug report
Virtualbox bug report and relevant comments (again)
i3 bug report
void QXcbWindow::handleConfigureNotifyEvent(const xcb_configure_notify_event_t *event) { // ... // FIXME: In the case of the requestedGeometry not matching the actualGeometry due // to e.g. the window manager applying restrictions to the geometry, the application // will never see a move/resize event if the actualGeometry is the same as the current // geometry, and may think the requested geometry was fulfilled. QWindowSystemInterface::handleGeometryChange(window(), actualGeometry); // ... }