The report T74067 shows how the interface code can operator on stale data when buttons activate immediately after handling an undo event.
This is an experimental patch that changes event handling so operators always finish handling events so the user interface doesn't end up operating on freed/invalid.
This has the down-side that events are more likely to build up in the queue.
To mitigate this, the flag OPTYPE_REFRESH_BYPASS has been added so operators which are likely to run on key-repeat such as text entry or frame-change can handle multiple events without a full refresh.
Note that I'm not all that satisfied with this solution, changing all operators event handling behavior to account for an extremely rare bug. Having said this, I'm not sure of a better alternative.
- Could we avoid unnecessarily updates from early exiting the event queue by detecting which operators remove data?
For ID's this is straightforward, for non-ID data this gets difficult, unless we rely on the operators themselves to return this information.
- We could have a different solution that avoids existing the event loop early and instead only refreshes the UI.
I'm wary of this as it means UI drawing would have two different code-paths which create the layout, adding some potential for small differences between being constructed in the main event loop and while handling the event queue - which could lead to bugs.