If RequestConnection fails, MC disregards the specific error, and just claims a network error occurred: if (tperror) { g_warning ("%s: RequestConnection failed: %s", G_STRFUNC, tperror->message); g_signal_emit (connection, signals[CONNECTION_STATUS_CHANGED], 0, TP_CONNECTION_STATUS_DISCONNECTED, TP_CONNECTION_STATUS_REASON_NETWORK_ERROR, NULL); return; } This is not very helpful. My reading of the spec is that accounts with invalid parameters should be marked with Valid: False. I don't think that would be helpful either. ;) We should probably use the DBus error name returned by RequestConnection—in this case, InvalidArgument. (I've checked Empathy and it currently doesn't do anything useful with InvalidArgument, but that could be changed.) I can't really see any better Connection_Status_Reason than None_Specified. :( (Obviously, this is a sign that I should add validation to the new “Username” field in Empathy for IRC accounts.)
Turns out I had a branch for this a few months ago but got distracted by a bee. Here it is...
Created attachment 72715 [details] [review] Remove McdAccount::connection-status-changed signal Nothing listens to it.
Created attachment 72716 [details] [review] Communicate the detailed error from McdConnection to McdAccount In particular, this propagates the error from RequestConnection failing correctly, so add a regression test for that.
++
Fixed in git for 5.15.0.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.