Priority: P3: Somewhat important
Affects Version/s: 5.15.2
Fix Version/s: None
Environment:Windows 10, on at least two computers with different hardware. No High DPI display mode
The problem occured somewhere between 5.11.1 & 5.15.2
Symptom from user point of view:
For some dialogs, if they are open on the primary screen, the menus (on QToolButton, on Combobox, on anything that relies on mapToGlobal()..) will appear at the wrong position.
If the dialog is open on the second screen, the issue is not there. It depends on the screen the dialog was open on, not the screen the dialog is currently on. And the error is also there if there is only one screen connected
What i could see by debugging:
-mapToGlobal() returns incorect X&Y
-because globalPositon() returns invalid X& Y
-because for one of the parent widgets, the rect of the widget is valid, but the geometry of the associated QPlatformWindow is invalid with some incoherent X&Y somewhere in the middle of the actualwidget
For some dialogs, i diagnosed that the problematic widget was a QStackedWidget, and simply adding widgets to it AFTER the layout that contains it had been set on a widget made it behave properly (compared to having the problem if the widgets are added to the stack before adding the stack to the layout and setting the layout on a widget). So there might be some layout updates that are not done anymore in that case.
For some other dialogs, the problematic widget is a widget that uses code generated bu UIC from a UI file, and i found no user code modif that could work around it. Basically any child widget that uses mapToGlobal() can have wrong behaviour because of this.
I'm not sure if this can help pinpoint the issue, but on the same dialogs with the QStackedWidget, i used to have a widget the used to be invisible (drawn before/under the others?) in 5.11.1. But with 5.15.2, also ONLY when the dialog is created on the first screen, that widget is now visible. So the same root problem might also affect widget draw order.
I first thought it was an incomplete fix of
QTBUG-84462, but the problem seems to be occuring a lot earlier at dialog creation here. And that wrong offset is somehow kept later, since after moving or resizing the dialog, the menus still open with the same offset error
If there is a temporary workaround to force recalculation of the geometry in the QPlatformWindow of a widget, it is welcome