Prompt the user when they attempt to log out or close the application when actions are pending

[redshiftzero]

related to #410, a user doesn't have an easy way to see what actions are pending to infer that they might lose some ongoing activity. we could offer a (dismissible) message in the following situations (potentially with different messaging) when the user attempts to logout or close the client application:

1. State-changing actions have not completed - reply send, flag, star/unstar, delete.
2. File downloads have not completed - these may be long running and if a 500 MB file is 1 MB away from completion, the user might just want to wait.

In both these scenarios, we could have the user elect to wait, resume next time (when #410 is implemented) noting that some of these actions may be out of date e.g. stale replies (to be discussed in #410), or offer a cancel button that enables them to cancel all the pending jobs.

[ninavizz]

Long long ago and in a wireframe far far away, the above was alluded to with casual language and outdated UI conventions as shown below.

A very simplified version with the standard alert bang, custom H1 & body text, and a "Cancel/Continue" binary as a standard Top Bar Message, feels like it'd be a great option for Beta. If possible. If. Possible.

[redshiftzero]

dope, this looks great. if we don't show the ETA and simplify the contextual messaging (maybe just the two states above) this could be doable

[eloquence]

Note that the user may exit the client by closing the application window; placement near username may be confusing in that case.

[ninavizz]

^ Yeah, that's where the conversation kinda went as I recall, in the design review for this. "Why bother with a rich sign-out experience, when users will most likely just close the VM window?" That may be what prompted the idea of having a pulsey-something that's not obnoxious but subdued, on the right side of the blue top bar's gradient, when network activity things are happening?

I think surfacing all the behavior in the Sync Widget status messages, should help a lot. For Beta, that tbh feels adequate. I know custom animations in QT are a big unknown on the team... which just shdn't be a priority abreast all the others, for Beta.

[ninavizz]

Adding to #650

[eloquence]

Because the queue is not visible in any way to the user, I believe this is an important issue for the beta. Perhaps not quite release blocker level -- we can warn users about exiting the client prematurely -- but close. Even with foreknowledge, if we don't warn them about pending operations, there's no way for them to fully know whether all operations (e.g., stars) have completed.

I propose the first iteration of this should be a simple warning-styled dialog window:

There are network operations that are still pending. If you [sign out / exit] now, some of your changes will be lost. Are you sure you want to discard your changes?

Cancel
OK

(It may be preferable to have clearer labels on the buttons, to be more explicit about which action signs the user out/

It's crucial that the user sees it even if they quit the client, so we can't really integrate it with the "Sign out" button (as seen in the mockup above).

[ninavizz]

Proposing this, as an iteration of Erik's iteration.

H1: Are you sure?
Body: The SecureDrop application and server are still processing some tasks. If you sign out now, those tasks will be lost. What would you like to do?
Actions:[ Cancel ] [ Sign Out ]

Cancel wd cancel whatever the prior user action was (signing out, or closing the window).
Sign Out would either sign the user out, or close the window (and while also signing them out).
IF primary/secondary button styling are an option, "Cancel" should be the primary—but still positioned on the left. I need to check that pattern, but for a high-consequence screen that feels right.

[redshiftzero]

If we're just downloading messages and replies (which can take a while if there's a lot of content on the server), would we want to still raise this dialog? I think we'd only want it for pending state changes the user wants to apply to the server (starring/deleting/sending a reply) and for long-running file downloads.

It's worth noting that since this issue was filed, the user can now see in the UI that

1. deletions are pending and have not been completed and
2. that replies are pending and have not been completed. And for replies if they sign out anyway with pending replies the content of the reply is not lost so that's good.

[ninavizz]

Nah, it should only flag if the user has performed input actions that would otherwise be lost. That's the standard pattern. If the client is just set to receive inputs others already sent to the server, those can all be resumed later; the authenticated user's inputs, otoh, wd be lost if they sign out.

TL;DR, we don't want anyone to lose data via this message. Both of the use-cases you cite, Jen, would do exactly that—it would lose an action from a user to the server.

[sssoleileraaa]

@cfm - just throwing this on your radar since we've discussed it a bit when talking about #1420 and #1452