A test plan describing how to trigger a disconnect would help reviewing that patch.

That's easy, join the lobby in one window, join the lobby in a second window.

Looks like this: (the name is taken from username)

Seems like all chat activity remains after reconnecting
(can't test with no activity happening in svn)
which to me it would be the greatest use of the pach.
I see someone fixed a bug that bothered me so much,
before now when you used widowed mode and opened a second lobby, the option got wiped from config file and next time you started the game it started in full screen and the options page started with unsaved values. Glad that's fixed.

Why showing a dialog in the first place at all and not automatically reconnecting in the background (with exponential back-off, ...) and only showing a dialog of that continues to fail?

Dunedan, I see a problem with that. If you open a second window and join multiplayer, both windows would fight to auto reconnect. Maybe it's best to give the user the decision.

In D791#49737, @mapkoc wrote:

Dunedan, I see a problem with that. If you open a second window and join multiplayer, both windows would fight to auto reconnect. Maybe it's best to give the user the decision.

What would be a legit case to do that?

I don't know if legit.
That's how some players access lobby while playing a game.
I open a second 0ad when replacing by ip to copy credntials before leaving as spec (sometimes I have forgotten and enter lobby with second client).
As mod I may need to check someone's host while playing (I don't think I can see that otherwise).

An alternative is to connect using a regular XMPP client instead of a second instance of 0ad. As the second XMPP client uses another resource identifier it's not causing any problems.

I'm actually surprised about your statement that it's possible to connect with two 0ad instances in parallel. When I try to do that I immediately get disconnected with the first instance when I connect using the second instance. That's how it XMPP is supposed to work anyway.

In D791#49738, @Dunedan wrote:

In D791#49737, @mapkoc wrote:

Dunedan, I see a problem with that. If you open a second window and join multiplayer, both windows would fight to auto reconnect. Maybe it's best to give the user the decision.

What would be a legit case to do that?

A feedback loop should certainly be prevented, even if lobbyists do something they shouldn't.
But since it doesn't actually "auto reconnect" but asks the user for confirmation, there is no infinite reconnect loop, but only a handful of message boxes until the player gets tired of the message box.
(Exactly the reason why there should be a message box)