bugfix: proper fix for history-paste crashes #17455
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
We already had code to skip pasting to the image currently being edited in darkroom (to avoid similar issues), but that code explicitly allowed the paste if the operation was started from darkroom view -- since otherwise pastes to the current image become impossible. When doing bulk history operations, we now check whether one of the involved images is the current darkroom image, and if so, we process it synchronously (which has already proven to avoid the crash) before queuing the rest.
ralfbrown
added
bugfix
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We already had code to skip pasting to the image currently being edited in darkroom (to avoid similar issues), but that code explicitly allowed the paste if the operation was started from darkroom view -- since otherwise pastes to the current image become impossible.
When doing bulk history operations, we now check whether one of the involved images is the current darkroom image, and if so, we process it synchronously (which has already proven to avoid the crash) before queuing the rest.
Full fix for #17452. Unlike #17453, it won't be possible to have cases like copying from one image on the filmstrip, moving to another, selecting all and then pasting. It would even be immune to switching to another image which gets its history updated after switching if we weren't already preventing that by limiting user interaction to cancellation until the job completes.
Apply on top of #17453 (already merged).