dab0ef3670
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> |
||
|---|---|---|
| .. | ||
| dialogs | ||
| effects | ||
| graphicsview | ||
| itemviews | ||
| kernel | ||
| styles | ||
| util | ||
| widgets | ||
| CMakeLists.txt | ||