1. we should *never* try to connect to unknown wireless networks
2. we should not ever loop over them
3. we should prompt the user when no networks are connected but only when no networks are connected and networks are available

Also NM should not try to connect to (known) wifi networks if there's wired connection (with a gatewya to the internet) present.

AFAIK, this has nothing to do with GNOME Shell... connection policy is all done in the NetworkManager core.

(I don't think the real problem here is the lack of the disable-wifi switch)

The problem here isn't unknown connections, right? It's protected connections where you don't want to dig out your RSA key, or connections you've previously tried to connect to (perhaps accidentally)

(It's a long-standing bug that NetworkManager remembers connections that you accidental select and tries to connect to them again later.)

It seemed to me to be about unknown connections as well since Matthias said "all the protected APs".  Matthias, have you connected to all those before?  I've only connected to one in the office.

I've never seen NetworkManager try to connect to a unknown connection, though I've frequently cursed at for trying to reconnect to a protected connection that I selected by accident.

Which to me is still unknown/untrusted.  But ok.

(In reply to comment #2)
> Also NM should not try to connect to (known) wifi networks if there's wired
> connection (with a gatewya to the internet) present.

Wrong, NM has been doing this for years since NM 0.7 with multiple active connection support.  There's no reason  not to do this, except when things fail like mclasen has found.  But in that case, we want to stop NM from asking you for the details again and just fail the connections silently (or with a notification, but certainly not a dialog).

NM itself will never connect to anything it's not told to connect to either by a client or stored config.

But note that network.js has some weird code in it (that I've commented on before) that will automatically connect to stuff even if you've never connected to it before:

        // XXX: what else to do?
        // for now, just pick a random network
        // (this function is called in a corner case anyway, that is, only when
        // the user toggles the switch and has more than one wireless device)
        if (this._networks.length > 0) {
            let connection = this._createAutomaticConnection(this._networks[0]);
            let accessPoints = sortAccessPoints(this._networks[0].accessPoints);
            this._client.add_and_activate_connection(connection, this.device, accessPoints[0].dbus_path, null);
        }

(I don't think the comment about multiple devices is correct there; this code fires even for one device when you hit the on/off switch)

I don't think the network menu should be doing this.  It shouldn't be picking a random access point and telling NM to connect to it just because you clicked the wifi on/off switch to on.  If the switch gets clicked on, then either you have previously connected access points that NM will automatically connect to, or nothing should happen because you haven't connected to anything in this location before.  But the shell shouldn't be telling NM to connect to random APs the user hasn't explicitly clicked on.

(In reply to comment #7)
> (In reply to comment #2)
> > Also NM should not try to connect to (known) wifi networks if there's wired
> > connection (with a gatewya to the internet) present.
> 
> Wrong, NM has been doing this for years since NM 0.7 with multiple active
> connection support.  There's no reason  not to do this, except when things fail
> like mclasen has found.  But in that case, we want to stop NM from asking you
> for the details again and just fail the connections silently (or with a
> notification, but certainly not a dialog).

In general, why would you connect to a wireless network when there's a wired one?
If it's resuming a previous known state (already connected in the past to the same wired and wireless networks at the same time) ok, but if the system is already connected to a wired connection (to the internet) I don't see a reason to try to connect to the a (even known) wireless one automatically.

(In reply to comment #8)
> NM itself will never connect to anything it's not told to connect to either by
> a client or stored config.
> 
> But note that network.js has some weird code in it (that I've commented on
> before) that will automatically connect to stuff even if you've never connected
> to it before:

ok, reassigning back to gnome-shell

(In reply to comment #8)
> NM itself will never connect to anything it's not told to connect to either by
> a client or stored config.
> 
> But note that network.js has some weird code in it (that I've commented on
> before) that will automatically connect to stuff even if you've never connected
> to it before:
> 
>         // XXX: what else to do?
>         // for now, just pick a random network
>         // (this function is called in a corner case anyway, that is, only when
>         // the user toggles the switch and has more than one wireless device)
>         if (this._networks.length > 0) {
>             let connection =
> this._createAutomaticConnection(this._networks[0]);
>             let accessPoints =
> sortAccessPoints(this._networks[0].accessPoints);
>             this._client.add_and_activate_connection(connection, this.device,
> accessPoints[0].dbus_path, null);
>         }
> 
> (I don't think the comment about multiple devices is correct there; this code
> fires even for one device when you hit the on/off switch)
> 
> I don't think the network menu should be doing this.  It shouldn't be picking a
> random access point and telling NM to connect to it just because you clicked
> the wifi on/off switch to on.  If the switch gets clicked on, then either you
> have previously connected access points that NM will automatically connect to,
> or nothing should happen because you haven't connected to anything in this
> location before.  But the shell shouldn't be telling NM to connect to random
> APs the user hasn't explicitly clicked on.

No the comment is correct: this is the handler for the device specific switch. In fact, each device, if it's showing its title, will get also a switch, that is unrelated to the global one. The global, on change, will frob the wireless-enabled property, while the specific will call activate() on the NMDevice.
I wouldn't replicate that policy, if I had an Activate per device, similar to Disconnect, but I don't have it, and a switch that only works for a half seems very bad.

(In reply to comment #11)
...
> No the comment is correct: this is the handler for the device specific switch.
> In fact, each device, if it's showing its title, will get also a switch, that
> is unrelated to the global one. The global, on change, will frob the
> wireless-enabled property, while the specific will call activate() on the
> NMDevice.
> I wouldn't replicate that policy, if I had an Activate per device, similar to
> Disconnect, but I don't have it, and a switch that only works for a half seems
> very bad.

I'm a bit confused by this comment. Giovanni - is GNOME Shell requesting the connection?

Kind of. If you activate the device specific switch (normally hidden), it will try to activate something (normally, the most recently used connection, or just any that is valid for the device if none), and failing that, it will try to create a new connection, as if you clicked on the "Auto ***" item.

It sounds like everyone is saying that their components are doing the right thing. Matthias - are you still experiencing the bug?

I haven't seen this in a while, so we should perhaps close this bug.