Currently, Quick Reblog erases the popup state (actually sets lastPostID = null, the flag to erase the popup state when the popup next appears, technically) unconditionally during the reblog process. This means that API errors not only cause a failure of the user action, but result in them losing their entered tags.
This moves the clear action to after the await, so that it only occurs on success. Users can thus try again, and/or copy their tags elsewhere in order to do the reblog through the normal post form without losing their work.
I had to go git blame the conditional here because I couldn't figure out exactly what it was for.
Testing steps
Force an API fetch failure (such as by unreverting the test commit).
Write tags into the quick reblog popup form.
Attempt the reblog. Dismiss the failure modal.
Hover over the reblog button on the same post. Confirm that the entered tags are still in the popup.
Hover over the reblog button on the a different post. Confirm that the popup is reset.
Perform a successful reblog and confirm that Quick Reblog works as normal.
(I didn't actually bother to test the delay-the-reblogPost-function-long-enough-to-move-to-another-post-while-it's-happening thing.)
Description
Currently, Quick Reblog erases the popup state (actually sets
lastPostID = null
, the flag to erase the popup state when the popup next appears, technically) unconditionally during the reblog process. This means that API errors not only cause a failure of the user action, but result in them losing their entered tags.This moves the clear action to after the await, so that it only occurs on success. Users can thus try again, and/or copy their tags elsewhere in order to do the reblog through the normal post form without losing their work.
I had to go git blame the conditional here because I couldn't figure out exactly what it was for.
Testing steps
(I didn't actually bother to test the delay-the-reblogPost-function-long-enough-to-move-to-another-post-while-it's-happening thing.)