Thanks for a bug report. I tried to reproduce this with (to be) 3.10.4, and the account detail lookup eventually ends, after several seconds of lookupping. 

Could it be that the api.gnome.org server was not responding to you on time?

I would try to get bactrace of running evolution in the wrong state. Please install debuginfo packages for evolution-data-server and evolution, then run evolution from a console (maybe some related runtime warnings will be printed), you can safely ignore those from gtk_entry:
> Gtk-CRITICAL **: gtk_entry_set_text: assertion 'text != NULL' failed
When you reproduce the issue, just capture the backtrace with the blow command. You can run it even several times, to see whether it does any progress.

   $ gdb --batch --ex "t a a bt" -pid=`pidof evolution` &>bt.txt

Created attachment 269779 [details]
back trace

Thanks for the update. The backtrace doesn't show any pending activity with the api.gnome.org, from which I suppose it was finished, either properly, or with an error. Otherwise the backend shows some webkit-related threads and one active IMAP+ account. The other threads are expected and waiting for orders.

If you run evolution from a terminal, does it print any critical warnings there, especially in time of the communication with api.gnome.org? Could you record the communication with api.gnome.org, to see what was sent and what was received, please? Such communication cannot be turned on with an environment variable, unfortunately. I'm also interested in exact URL being used in the request to the api.gnome.org server. For example, I can do this:
   $ wget http://api.gnome.org/evolution/autoconfig/1.1/localhost
which "fails" with 404, while the call to
   $ wget http://api.gnome.org/evolution/autoconfig/1.1/gmail.com
succeeds and returns an XML blob.

I saw the following in a network capture.

It resolves api.gnome.org to proxy.gnome.org
It resolves A and AAAA records for proxy.gnome.org

GET /evolution/autoconfig/1.1/localhost HTTP/1.1\r\n
320 Found
It returns a short HTML document. The interesting part is
<p>The document has moved <a href="https://api.gnome.org/evolution/autoconfig/1.1/localhost">here</a>.</p>
connection is closed

My computer connects to proxy.gnome.org:https by TLS.
Encrypted link is set up. I don't know the contents.
connection is closed

My computer connects to 192.0.80.240:https by TLS
the connection is not closed

My computer connects to 93.184.220.111:https
The TCP connection setup completes but there is no traffic

Evolution gives this output
(4*) Gtk-CRITICAL **: gtk_entry_set_text: assertion 'text != NULL' failed

Then, at the point where it gets caught
GLib-GIO-CRITICAL **: g_task_return_error: assertion 'error != NULL' failed
GLib-GIO-CRITICAL **: g_task_propagate_boolean: assertion 'task->result_set == TRUE' failed
evolution-mail-CRITICAL **: mail_config_assistant_autoconfigure_cb: assertion 'E_IS_MAIL_AUTOCONFIG (autoconfig)' failed

(In reply to comment #5)
> Evolution gives this output
> (4*) Gtk-CRITICAL **: gtk_entry_set_text: assertion 'text != NULL' failed

These are harmless, and there exists a bug report in gtk+ to avoid that critical warning, the same was as it is avoided for GtkLabel.

> Then, at the point where it gets caught
> GLib-GIO-CRITICAL **: g_task_return_error: assertion 'error != NULL' failed
> GLib-GIO-CRITICAL **: g_task_propagate_boolean: assertion 'task->result_set ==
> TRUE' failed
> evolution-mail-CRITICAL **: mail_config_assistant_autoconfigure_cb: assertion
> 'E_IS_MAIL_AUTOCONFIG (autoconfig)' failed

Aha, I see, this might be it, it doesn't need to stop for you due to these critical warnings, especially due to the last one, which is a callback which is called after the discovery is done.

(In reply to comment #4)
> I saw the following in a network capture.

I suppose this is from evolution itself, right?

> It resolves api.gnome.org to proxy.gnome.org

because I do not see the redirect when I issue the wget command (comment #3), it shows for me:

$ wget http://api.gnome.org/evolution/autoconfig/1.1/localhost
--2014-02-27 11:27:00--  http://api.gnome.org/evolution/autoconfig/1.1/localhost
Resolving api.gnome.org (api.gnome.org)... 209.132.180.180, 209.132.180.168
Connecting to api.gnome.org (api.gnome.org)|209.132.180.180|:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://api.gnome.org/evolution/autoconfig/1.1/localhost [following]
--2014-02-27 11:27:01--  https://api.gnome.org/evolution/autoconfig/1.1/localhost
Connecting to api.gnome.org (api.gnome.org)|209.132.180.180|:443... connected.
HTTP request sent, awaiting response... 404 Not Found
2014-02-27 11:27:02 ERROR 404: Not Found.

For the network capture, I had all other identified software which generates traffic except for DNS shut down.
If you do
dig api.gnome.org
then you see it returns a record
CNAME	proxy.gnome.org.
but no address records for api.gnome.org. The address records used are for proxy.gnome.org. This is what I saw in the network log.

The console output was from Evolution only.

OK, I see the CNAME too, but I would like to see the wget output from you machine too, unless it's the same as for me.

On the other hand, the reason for this critical warning:
> GLib-GIO-CRITICAL **: g_task_return_error: assertion 'error != NULL' failed
may cause the other things work.

It could be a lame question, but what is your glib2 and libsoup version, please? I use:
   glib2-2.38.2-2.fc20.x86_64
   libsoup-2.44.2-1.fc20.x86_64
and do not see those runtime critical warnings on my machine.

As another test, could you install debug info packages for libsoup, evolution-data-server and evolution, run evolution under valgrind:
   $ G_SLICE=always-malloc valgrind --num-callers=50 evolution &>log.txt
and try to reproduce the issue, please? Please note that:
a) evolution will be very slow, due to all memory checking
b) it may not crash, but the log.txt can contain the reason for the error
c) it is not 100% that it'll contain the reason, when this is not related to
   a use-after-free or any other memory-related issue, which valgrind checks for

I did some debugging, since we ran into this on SLED 12 SP2 (running evolution 3.20.5).
If the nameserver doesn't have an entry for localhost, then mail_autoconfig_initable_init returns FALSE, and an error is set, so evolution behaves reasonably.
If the nameserver does have an entry for localhost, then the contents of the while loop are never executed, since name_server is set to "localhost", which contains no period, so the function returns FALSE without ever having set an error. I think that this is confusing glib.

I can't reproduce this under 3.26.2; I think that the refactoring for bug 750564 had the side-effect of fixing this bug.

Thanks for spending the time on the debugging. I cheated 3.24.x with gdb to mimic the situation you described and I then see on console three runtime warnings:

> evolution:1991): GLib-GIO-CRITICAL **: g_task_return_error: assertion
> 'error != NULL' failed
>
> (evolution:1991): GLib-GIO-CRITICAL **: g_task_propagate_boolean: assertion
> 'task->result_set == TRUE' failed
> 
> (evolution:1991): evolution-mail-CRITICAL **:
> mail_config_assistant_autoconfigure_cb: assertion 'E_IS_MAIL_AUTOCONFIG
> (autoconfig)' failed

The last warning causes that indefinite wait for the lookup end and inability to cancel it. As you said, this is fixed in 3.26 by the changes around the config lookup.

Created attachment 367754 [details] [review]
proposed patch

This patch is for pre-3.26 version, +/- path for the sources (it's generated against 3.22 sources, where is no src/ directory), it should fix the issue, basically all three runtime warnings mentioned in the previous comment.

Those runtime warnings also explain why there was not visible anything related in the backtrace provided earlier.

I cannot apply the whole change in the current sources, because the part at src/mail/e-mail-config-assistant.c doesn't exist any more, but I apply at least the first part, just for consistency.

Created commit 11e1359a01 in evo master (3.27.90+)
Created commit e6c3fc424c in evo gnome-3-26 (3.26.5+)

Thanks for the patch. I tested it on 3.20.5, and it fixes the bug for me. Going to add it to our spec for SLE/Leap.