path: root/tests/auto/corelib/io/qsettings/qsettings.qrc
diff options
authorLaszlo Agocs <>2022-06-28 15:30:28 +0200
committerLaszlo Agocs <>2022-07-01 22:38:45 +0000
commitdab0ef367089869910c38fe772f31da14fd5386e (patch)
tree43b55e71181f08b9c31618a4ec2cb32734aa9f2a /tests/auto/corelib/io/qsettings/qsettings.qrc
parent9ea2f7f4b1192f3429aa2d3e278097008bc773bb (diff)
Harden drag and drop handling in widget window
User code in an event handler can do arbitrary things, including operations that lead to destroying the QWidgetWindow. An example is what the autotest does: reparenting the top-level widget to under another top-level upon the drop. Internally this leads to destroying the drop target's QWidgetWindow as the widget is now a child, not a top-level. In fact some of the existing drag and drop handling code seems to be prepared to handle the case of having the drag target widget destroyed in the user's event handler during a drag-move. But none of it is prepared for having the QWidgetWindow destroyed upon returning from forwardEvent(). The associated bug report has the same root cause, it is just popping up now via the new 6.4 behavior: adding a QOpenGLWidget to a widget hierarchy upon a drop leads to getting a new QWidgetWindow (if the window only had regular raster widgets before). To solve this, avoid touching members on 'this' after the forwardEvent(). It looks like the handlers for mouse events follow this pattern already, no member data is touched after forwarding events (not sure if that is intentional or just incidental but it is the safe solution, even if this is not feasible everywhere, but ideally input events should take this into account). Fixes: QTBUG-104596 Pick-to: 6.4 6.3 6.2 Change-Id: I96c704cadcd799fc5619b776e939dfdf313a27dd Reviewed-by: Shawn Rutledge <> Reviewed-by: Volker Hilsheimer <>
Diffstat (limited to 'tests/auto/corelib/io/qsettings/qsettings.qrc')
0 files changed, 0 insertions, 0 deletions