(In reply to Carlos Soriano from comment #0)
> I have an error while connecting to gimp.net and it says "check the address
> is correct"

Mmh yeah, we need to do something about that. That error message, which was added in 3.18, was always much more hand-wavey than it sounds. We know something went wrong, and for custom connections (which was all we had before 3.20), a configuration error simply is the most likely cause.

But now that we encourage users to create connections from a list of predefined networks, it's not only unlikely that the server settings are wrong, the message is complete bogus as we don't even show the network settings in that case.


> An idea would be to add the address in the properties dialog to allow
> editing it.

I don't think that's a good option. Since bug 762335 landed, we actually try all servers for the network before failing, so if none of the predefined servers work, it's unlikely that the user could actually fix this by changing the address.

So I'd say let's make this bug about improving the error handling in that dialog.

(Regarding your issues: Is that a new connection created with 3.20.x, or an older one using the control-center's online accounts panel? In case of the latter, the relevant section of ~/.local/share/telepathy/mission-control/accounts.cfg might provide some clues)

I agree, improving the error message to not say to check the address would be enough to avoid the confusion.

> (Regarding your issues: Is that a new connection created with 3.20.x, or an
> older one using the control-center's online accounts panel? In case of the
> latter, the relevant section of
> ~/.local/share/telepathy/mission-control/accounts.cfg might provide some
> clues)

It's a new connection with 3.20 dialog, so I guess this is not applicable.

(In reply to Carlos Soriano from comment #2)
> It's a new connection with 3.20 dialog, so I guess this is not applicable.

Mmh, in that case, are you still on 3.20.0? Some of the GNOME servers have been on-and-off recently, but having all of them fail seems fairly unlikely. The aforementioned patch in bug 762335 only landed in 3.20.1 ...

(In reply to Florian Müllner from comment #3)
> (In reply to Carlos Soriano from comment #2)
> > It's a new connection with 3.20 dialog, so I guess this is not applicable.
> 
> Mmh, in that case, are you still on 3.20.0? Some of the GNOME servers have
> been on-and-off recently, but having all of them fail seems fairly unlikely.
> The aforementioned patch in bug 762335 only landed in 3.20.1 ...

3.20.2 . It's strange I tried several times with reconnect, however only start working again when I remove/add the connection again. Even then sometimes were failing, but after the third remove/add it works now.

(In reply to Florian Müllner from comment #1)
> Since bug 762335 landed, we actually try all servers for the network before
> failing, so if none of the predefined servers work, it's unlikely that the 
> user could actually fix this by changing the address.

... and as it turns out, there's a race condition at startup that breaks the fallback code.

Created attachment 329061 [details] [review]
networksManager: Refactor code a bit

We are about to load the initial networks list immediately, but may
want to asynchronously fetch an up-to-date list from the network
in the future. So split out a parseNetworks() function that can be
used in both code paths.

Created attachment 329062 [details] [review]
networksManager: Load initial networks list synchronously

Loading a file from a resource is super-fast as it does not involve IO,
so there's no real reason to do the operation asynchronously, in
particular as we initialize the networks manager singleton before any UI
is shown. It does open the door for race conditions on startup though,
which we can easily avoid by loading the initial list synchronously.

This doesn't fix it for me :(

Created attachment 332598 [details] [review]
app: Fix filtering of alternate servers

When connecting to a server of a predefined network fails, we use
the list of servers to keep trying. The intention of the code is
to skip the server that already failed, but as we currently compare
an object to a string, we end up including it anyway.
Fix the filtering function to produce the expected result.

Created attachment 332599 [details] [review]
app: Set 'use-ssl' when retrying with another server

When creating an account from a predefined network, we always use
SSL when available. Likewise, all servers return by the networks
manager will be SSL-enabled if the networks supports it. So in
theory, the 'use-ssl' parameter should already be correct and
we don't need to update it. However there have been reports
where the parameter got unset for some reason, with the result
that all connection attempts fail. While it would be interesting
to figure out how exactly the parameter is lost, setting it
anyway when retrying with another server is still a good idea,
as account could always have been modified externally.

So this is what I was running in last night - I have no idea how this happened, but suddenly all connection attempts to GNOME were failing, and after a while of poking around I figured that the 'use-ssl' setting was lost, and polari was trying to use plain connections with a list of SSL servers.

Let's see if that's the same issue you are seeing ...

(Also I'd be still interested in any pointers on *how* the setting is lost - I certainly didn't meddle with any account settings manually. Still, including it in the set of updated parameters as in the 2nd patch looks like the right thing to do anyway)

Thanks Florian!

I cannot reproduce now (deleted all accounts and added again, now it's working for one week).
I didn't manually touch any account neither, or any special manipulation, so I have no idea how this happened.

Will try the patch when I hit the bug again.

Review of attachment 329061 [details] [review]:

looks good to me.

Review of attachment 329062 [details] [review]:

looks good to me

Review of attachment 332598 [details] [review]:

looks good to me

Review of attachment 332599 [details] [review]:

looks good to me

Attachment 329061 [details] pushed as 2e93936 - networksManager: Refactor code a bit
Attachment 329062 [details] pushed as 57eceb2 - networksManager: Load initial networks list synchronously

Attachment 332598 [details] pushed as c25c029 - app: Fix filtering of alternate servers
Attachment 332599 [details] pushed as fac7220 - app: Set 'use-ssl' when retrying with another server

Pushed, as those changes still look like a good idea even when your particular issue turns out to be something else. Let's hope it's not though, so closing tentatively - please re-open if you still run into problems!