GNOME Bugzilla – Bug 662338
nm-applet password dialog shown before the shell one in some circumstances
Last modified: 2012-04-12 17:32:22 UTC
I happen to reproduce this quite often with this peculiar circumstances, but I think this might be a more general problem when an AP is not reachable anymore. - I often take a bus to commute to the office, and the bus waits for some minutes outside the office; I open the laptop while the bus is there, and it will connect to the office wireless - the bus takes the road, and after a bit the office AP is not reachable anymore - NM will lose the connection and will try to reconnect to the AP; while this happens, the indicator in the shell is in the "connecting" state (correct behaviour) - reconnection will fail, since the AP is not reachable anymore, and NM will prompt for the wireless password - I get the nm-applet GTK dialog for the password first; if I cancel it, I will get the shell one I'd argue there are two bugs here: 1. the shell dialog should be shown instead of the GTK one; at no point in this process I should see two consequent dialogs asking me the same thing 2. if the AP is not reachable anymore, there's no point in asking again for the password. Connection didn't fail due to an authentication error, but because the AP signal is not in range; we should detect that and just switch to disconnected state
None of this looks like a shell problem; I've talked with Dan a while ago about 1), apparently the order in which authentication agents are executed is "random" (the proper solution is to implement missing bits in the gnome-shell agent, so that nm-applet can die die die)
I saw another variant of this bug again; this time it was a genuine password request dialog (after having selected a network from the menu), and the GTK dialog hijacked the shell one. (In reply to comment #1) > None of this looks like a shell problem; I've talked with Dan a while ago about > 1), apparently the order in which authentication agents are executed is > "random" (the proper solution is to implement missing bits in the gnome-shell > agent, so that nm-applet can die die die) Is there any reason why nm-applet is needed at all in a non-fallback mode? What do we need to implement to eradicate it completely?
(In reply to comment #2) > (In reply to comment #1) > > None of this looks like a shell problem; I've talked with Dan a while ago about > > 1), apparently the order in which authentication agents are executed is > > "random" (the proper solution is to implement missing bits in the gnome-shell > > agent, so that nm-applet can die die die) > > Is there any reason why nm-applet is needed at all in a non-fallback mode? What > do we need to implement to eradicate it completely? VPN. Currently, each nm plugin provides its own authentication dialog and communicates with nm via pipes. It is definitively on the list of stuff-to-fix-for-3.4 ...
*** Bug 663169 has been marked as a duplicate of this bug. ***
I'm also getting this. As an extra bonus, entering the key into the first (GTK) dialog doesn't save it. Entering it into the second one (shell) saves it properly though. Odd...
*** Bug 665311 has been marked as a duplicate of this bug. ***
And it keeps on giving. It also manages to nuke the stored secret now and then when in this mode. Extremely annoying as it is not something you generally keep written down.
(In reply to comment #7) > And it keeps on giving. It also manages to nuke the stored secret now and then > when in this mode. Extremely annoying as it is not something you generally keep > written down. I think that the fact that it loses the secret is a different issue you reported elsewhere, please don't mix separate problems.
The other issue I reported was that it kept popping up the question. In those cases it is always filled in the secret though. I've only seen it actually lose the secret when the scenario here occurs. Could certainly be a different bug, but they seem correlated.
We're talking about bug 665680, right? You didn't mention the old nm-applet dialog appearing in that report. That would indeed be valuable information.
Bug 665680, right. But no, it does not appear. To clarify: Bug 662338 (this bug): - sometimes nm-applet dialog pops up - when this happens, sometimes also the secret is forgotten Bug 665680 (other bug): - Sometimes it starts nagging me with the gnome-shell password dialog on each and every connection. I have not (yet) seen the nm-applet dialog in these cases. For me these things also tend to happen at different times. This bug only happens when NM has connection problems (which happens because of other NM/iwl bugs), whilst the other bug is also for "normal", well functioning connections.
Got the lost password here again. This time I kept monitoring the state of things with nm-connection-editor. The password is lost somewhere after I close the nm-applet dialog and before the gnome-shell dialog. So right now it would point at nm-applet having the bug that wipes the secret.
Pierre: Good news, I've also experienced the lost passphrase issue. I've filed it separately as Bug 668251 since I realized the present report is really about a different issue (see my report).
*** Bug 673995 has been marked as a duplicate of this bug. ***
It's worth mentioning that this specific bug has been now fixed for GNOME 3.4 - you need network-manager-applet from git and gnome-shell >= 3.4.0. I'm closing this as FIXED, since the other issues mentioned in the comments of this report have separate bugs already.