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 <shawn.rutledge@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
dab0ef3670