"Export successful" message displayed prematurely

[eloquence]

Tested in 0.1.6 release of the client on production Qubes setup, i.e. the full current production configuration, using the STR below, but simpler STR may suffice.

STR

1. Submit 3 files as a new source through the SI.
2. Sync with the client to pick up those files.
3. Download all 3 files using the client.
4. Export each individual file to a LUKS drive.

Expected behavior

All files are exported successfully after the user types in the password.

Observed behavior

For one of the files, "Export successful" message appears before the user types in the password. Only subsequently, the user is prompted to enter their password, and the export actually completes.

[eloquence]

This seems potentially race condition-ish, so may be difficult to repro exactly. In this particular test, I initially had the USB plugged in before sd-devices came up, which could have contributed to a problematic state. (If the drive is plugged in before sd-devices starts, it will never be attached, and initial exports will always fail.)

See also #990 which could relate to a similar problematic state.

[sssoleileraaa]

This is likely due to the way we reuse the continue button for different tasks. Throughout the export workflow we disconnect the continue button signal from its previous slot so that we can connect it to a new slot to handle the new step in the process. My guess is that when we are exporting a file, it is somehow connected to the export successful handler. I haven't looked into this theory, but it's something to check on.

[ninavizz]

Would this be a good time to insert that extra step, then, that I'm advocating for to address usability needs... which wd be to acknowledge that the user is now in "Passphrase accepted, export happening" mode?

It had previously been flagged that there was concern that such a screen cd be weird, as the export itself is likely to take just a few seconds... but I'd be ok setting such a screen to show for a minimum of 3 seconds (or however long one would reasonably need to read the minimal state change on the screen).

[eloquence]

@ninavizz The initial goal is to understand better when the bug occurs, and then we can scope a fix. Since it's a bugfix, we'll likely be conservative about additional UX changes just to resolve this issue.

I'll poke at this more during QA this sprint, but we'll most likely not attempt a fix until the next sprint.

[ninavizz]

@eloquence Understood... TL:DR in my comment, tho, was flagging that the export process could simply be happening much more quickly than the UI was built to support as-is? If that hypothesis is off, of course, I'll shutup and punt my UI request to a later ticket. :D

[rocodes]

I fixed this one a while back and didn't close it - closing now