Created attachment 242834 [details] [review]
proposed eds patch

for evolution-data-server;

This hides the prompt as soon as possible, before the try_password() is invoked, thus the caller can do anything there.

Matthew, what do you think about that? If I recall correctly, you left the password prompt opened during the try_password() phase only to give a chance to a user to cancel that phase, for a price of system model dialog being shown for a long time (with slow servers or such). I believe, that cancellation is supposed to be done on the client which invoked the password prompt, not by the password prompt itself, thus this change might not be an issue.

I made the password dialog stay up until we have an authentication result because I hate the behavior where it disappears immediately and I have no idea what just happened -- did it work?  did it not work?  did something crash?  is the thing gonna pop back up in my face again in a few seconds?  I'd hate to see E-D-S regress back to that.

I agree with what Stef said in another bug -- that we shouldn't be prompting about certificate validity like web browsers do.  If the certificate is invalid or not trusted, the connection fails.  Period.

We just need to work out how to indicate that something has gone wrong and how to direct the user into correcting it.  Preferably without imposing too many new requirements on all E-D-S clients.

(In reply to comment #2)
> I made the password dialog stay up until we have an authentication result
> because I hate the behavior where it disappears immediately and I have no idea
> what just happened -- did it work?  did it not work?  did something crash?  is
> the thing gonna pop back up in my face again in a few seconds?  I'd hate to see
> E-D-S regress back to that.

I do not agree. You changed the password prompts in 3.6+ to be centralized in one place, which means the password prompt is not tight to the application which asks for it, as it used to be. You cannot expect the 3rd party dialog (the password prompt) doing the same what the client which asks for the password is responsible for. It just doesn't work, because you've two places where you can cancel the authentication session now. One is on the client, which is the only correct place. The other is the stale gcr prompt serving for nothing but block whole session under gnome-shell (luckily other desktops have it semi-system model).

> I agree with what Stef said in another bug -- that we shouldn't be prompting
> about certificate validity like web browsers do.  If the certificate is invalid
> or not trusted, the connection fails.  Period.

Well, I do not agree here as well. Despite the trust prompt suffers of the same issue as password prompts, the window not being tight to the application which invoked it, the trust-prompt makes sense. It's basically the same question as ssh points to you when you either connect to the server for the first time, or when the server changes its certificate. The later, when the server changes its certificate, is the main reason why the certificate dialog is good to have. At least from my point of view.

For example, Google's certificates will expire at the end of this year, which is no problem as long as they'll use a provider which will be set as trusted in user's certificate database. They use Equifax currently, which expires on 08/22/2018. Supposing you'll still use the same machine after 5 years, for which you might not receive any updates meantime, you might be asked for a certificate trust even for the Google server.

Of course, the main issue is that the password prompt through gcr blocks user from everything else, which is plain wrong when user already entered his/her password, as is indicated in several other bug reports already (I recall one being against system modal popups in general, one about inability to use Google's generated passwords for two-factor authentication, because users cannot generate the application password when the password prompt blocks whole session). I'm sorry, but all that feels like using gcr here was not the best idea, and is the main regression from 3.4- times, where eds provided its own password prompt dialog, which was not system modal.

> We just need to work out how to indicate that something has gone wrong and how
> to direct the user into correcting it.  Preferably without imposing too many
> new requirements on all E-D-S clients.

Remember, this is about 3.8.x, where is for anything like this too late. In any case, that belongs to bug #694322.

Downstream bug report about basically the same, a claim that the password prompt is opened too long, with unresponsive server when a wrong password is entered, blocking whole desktop and user from his duty.

https://bugzilla.redhat.com/show_bug.cgi?id=957933

Further comments on Red Hat Bugzilla 957933:

Why would you do anything on a multi-processing, multi-tasking, modern user interface that constrains the user to waiting for a single task to time-out? Other teams handle this task asynchronously, why can't Evolution? I can understand not allowing any other Evolution activities, maybe. But to shut down the rest of the user interface? No. Especially since it is only really noticeable when the user has already made a mistake by entering a password incorrectly or the mail service has a problem.

Please fix this.

Matthew, I suggest to commit the proposed patch for 3.8.4, then return back to it for 3.10, or 3.12, if you'll find anything better. The thing is that the current user experience is bad, and your concerns (comment #2) are causing it.

The proposed patch wasn't fully correct, some use-after-free and so on could happen, at least on the current 3.12.x+. I updated it and:

Created commit 04a93c3 in eds master (3.13.7+) [1]
Created commit e7e84e8 in eds evolution-data-server-3-12 (3.12.8+)

[1] https://git.gnome.org/browse/evolution-data-server/commit/?id=04a93c3