Ensure correct unlocking of script editor history#113619
Conversation
f00d0e6 to
544bcb4
Compare
544bcb4 to
31307ce
Compare
|
The history tracking is still inconsistent when jumping to symbols or navigating back. Several functions, For example, when jumping to a symbol in another script, When moving back, |
|
I'm aware but it is not the point of this PR to address that. This perma locking thing makes debugging other history issues pretty rough so I want to have that sorted out first. |
kitbdev
left a comment
There was a problem hiding this comment.
Makes sense, fixes the issue.
|
Thanks! |
Related to and encountered while looking into #113042
Seems to be the same issue described in: Fixes #113502
The history can be locked, this is done when e.g. restoring the state from the history. Since this involves some deferred signals it can't be instantly unlocked. The approach till now was to unlock in some method that was connected to the deferred signal. But the signal is not consistently emitted. This PR instead defers the unlocking manually to ensure it always happens.
The fix relies on a certain behaviour of
call_deferred.The deferred call to emitting the signal happens before the deferred call to unlocking the history. So the method connected to the signal also runs before the history gets unlocked.
I added this to the documentation to ensure that this is considered stable enough to base a bugfix on it.