After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 660293 - NetworkManager password prompt block everything
NetworkManager password prompt block everything
Status: RESOLVED FIXED
Product: gnome-shell
Classification: Core
Component: network-indicator
3.2.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
: 677541 686566 693674 694933 707502 729197 740746 740750 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2011-09-27 21:16 UTC by Mildred
Modified: 2015-03-12 21:00 UTC
See Also:
GNOME target: 3.16
GNOME version: ---


Attachments
SecretAgent: differentiate user actions from automatic connections (3.70 KB, patch)
2012-06-14 18:47 UTC, Giovanni Campagna
none Details | Review
NetworkAgent: differentiate between user-initiated actions and automatic connections (4.90 KB, patch)
2012-06-14 18:47 UTC, Giovanni Campagna
reviewed Details | Review
NetworkAgent: differentiate between user-initiated actions and automatic connections (5.41 KB, patch)
2012-06-14 20:12 UTC, Giovanni Campagna
none Details | Review
NetworkAgent: differentiate between user-initiated actions and automatic connections (5.92 KB, patch)
2015-03-04 01:03 UTC, Giovanni Campagna
committed Details | Review

Description Mildred 2011-09-27 21:16:36 UTC
When NetworkManager request a wifi password, gnome-shell blocks the user interface. This is very inconvenient if I want to copy and paste the password from a text file.

We should find a way to let the user continue to use others programs in that case. I was thinking letting the user to trigger the activity view and from there, switch to other programs. The dialog box should still be very visible, for example, it could stay over the desktop when switched to another application, and when clicking on the desktop, it would reappear on the front.

All of this is also applicable to other shell dialogs, but wifi is the use case that makes me think there is a problem here.

Mildred
Comment 1 Milan Bouchet-Valat 2011-09-28 08:21:17 UTC
I guess the use case is that the first time you enter a password/key, you'd like to copy it from a text file? But in that case, you can still copy it beforehand, and then connect to the network, get the dialog and paste it. This means you need to know what you're doing, but typically if you're copying the password/key, you do.
Comment 2 Mildred 2011-09-28 12:51:54 UTC
Yes, but that's still inconvenient.

It would be something like:

- connect
- oh no, I have to type a password, I can't access my password file. cancel for
  now
- copy the password
- reconnect (if it takes time because of a buggy driver, don't override the
  clipboard)
- paste the password

Now, imagine that this modal dialog is used for other things, processes that can't be cancelled easily, or that takes time until a password is needed. That kind of things can become very inconvenient.

I like the new modal dialog but I just wanted to stress that it can also be a source of problems, and we should be aware of them.
Comment 3 Milan Bouchet-Valat 2011-09-28 20:06:36 UTC
(In reply to comment #2)
> Yes, but that's still inconvenient.
> 
> It would be something like:
> 
> - connect
> - oh no, I have to type a password, I can't access my password file. cancel for
>   now
> - copy the password
> - reconnect (if it takes time because of a buggy driver, don't override the
>   clipboard)
> - paste the password
>
>
> Now, imagine that this modal dialog is used for other things, processes that
> can't be cancelled easily, or that takes time until a password is needed. That
> kind of things can become very inconvenient.
Sure, in theory, but in the present case I don't think designers will consider making that dialog half-modal and kind of inconsistent is worth the gain you suggest. If a more problematic case appears, that will be another story.

> I like the new modal dialog but I just wanted to stress that it can also be a
> source of problems, and we should be aware of them.
I wasn't really in favor of modal dialogs either. But since we have it, I'm not sure "being aware" of these shortcomings brings us much if we can't find a reasonable improvement.
Comment 4 el 2012-06-11 22:27:59 UTC
(In reply to comment #3)
> I wasn't really in favor of modal dialogs either. But since we have it, I'm not
> sure "being aware" of these shortcomings brings us much if we can't find a
> reasonable improvement.

What about the old NetworkManager dialogs? Those were sufficiently modal to avoid typing the password into the wrong window (they were good at stealing keyboard focus when spawning and staying on top of everything), but still allowed explicitely setting focus to other windows if I recall correctly and therefore they wouldn't fully block the desktop up to being closed.
Comment 5 Jasper St. Pierre (not reading bugmail) 2012-06-11 22:42:09 UTC
A shell notification seems good for now.
Comment 6 Giovanni Campagna 2012-06-14 18:47:00 UTC
Created attachment 216444 [details] [review]
SecretAgent: differentiate user actions from automatic connections

Some secret agents implement system modal behavior for secret
requests, and would like to differentiate it for automatic connections
(as it could be annoying if a dialog pops up from nowhere)
Comment 7 Giovanni Campagna 2012-06-14 18:47:21 UTC
Created attachment 216445 [details] [review]
NetworkAgent: differentiate between user-initiated actions and automatic connections

If the action was initiated by the user, we want to show the
modal dialog immediately, while if the action was initiated by
NM autoconnection policy we first show a notification and then
show the dialog when needed.
Comment 8 Giovanni Campagna 2012-06-14 18:52:24 UTC
*** Bug 677541 has been marked as a duplicate of this bug. ***
Comment 9 Jasper St. Pierre (not reading bugmail) 2012-06-14 19:30:14 UTC
Review of attachment 216445 [details] [review]:

You are awesome.

::: js/ui/networkAgent.js
@@ +618,3 @@
 
+    _showNotification: function(requestId, connection, settingName, hints, flags) {
+        let source = new MessageTray.Source(_("Network Manager"), 'network-transmit-receive', St.IconType.SYMBOLIC);

I'm so glad I made this cleanup.

@@ +643,3 @@
+                let gsmSetting = connection.get_setting_gsm();
+                title = _("PIN code required");
+                message = _("PIN code is needed for the mobile broadband device");

Are you sure you want the fall-through here? These messages will never get used.

@@ +654,3 @@
+            log('Invalid connection type: ' + connectionType);
+            return;
+        };

No ;
Comment 10 Giovanni Campagna 2012-06-14 20:12:53 UTC
Created attachment 216457 [details] [review]
NetworkAgent: differentiate between user-initiated actions and automatic connections

If the action was initiated by the user, we want to show the
modal dialog immediately, while if the action was initiated by
NM autoconnection policy we first show a notification and then
show the dialog when needed.
Comment 11 Jasper St. Pierre (not reading bugmail) 2012-06-14 20:46:06 UTC
Review of attachment 216457 [details] [review]:

Sure.

::: js/ui/networkAgent.js
@@ +352,3 @@
                 content.secrets.push({ label: _("PIN: "), key: 'pin',
                                        value: gsmSetting.pin || '', password: true });
+                break;

Tee hee.
Comment 12 Florian Müllner 2012-06-14 21:34:54 UTC
(In reply to comment #5)
> A shell notification seems good for now.

Probably, but we should still wait for the designers to ACK this before pushing.
Comment 13 Giovanni Campagna 2012-06-25 17:14:01 UTC
(In reply to comment #12)
> (In reply to comment #5)
> > A shell notification seems good for now.
> 
> Probably, but we should still wait for the designers to ACK this before
> pushing.

Even before that, we need the flag in NetworkManager.

Dan, ping?
Comment 14 Dan Williams 2012-06-27 14:48:06 UTC
Pushed this patch to NM:

http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=74e262b3032b0e53df0cd0c64a752ad628042cf1

which adds a new secrets request flag USER_REQUESTED (0x04) which is set when the action which triggers the secrets request comes from D-Bus, instead of from an autoconnect action inside NM.  You should be able to use that in conjunction with some internal logic to figure out whether to show the notification or the modal shell dialog.
Comment 15 Allan Day 2012-06-27 16:10:37 UTC
Sorry, but I really don't like this. Notifications aren't a good fit for inputting passwords. It puts network passwords on the same level as chatting with a friend, and it's inconsistent with what we're doing elsewhere for authentication.

I think the real bug here is that we seem to be connecting to an unknown network without the user specifically requesting it.
Comment 16 Jasper St. Pierre (not reading bugmail) 2012-06-27 16:20:14 UTC
(In reply to comment #15)
> I think the real bug here is that we seem to be connecting to an unknown
> network without the user specifically requesting it.

This has nothing to do with this bug. Read the first description: he explicitly connected to a network, but realizes he needs the password, which he keeps a file on his disk. He cannot get to it while the modal prompt is running.
Comment 17 Matthias Clasen 2012-06-27 17:02:24 UTC
But... according to giovannis' description of his patch, if the user explicitly connected, we still show the modal right away. So how does this even help ?!
Comment 18 Allan Day 2012-06-27 17:25:02 UTC
(In reply to comment #17)
> But... according to giovannis' description of his patch, if the user explicitly
> connected, we still show the modal right away. So how does this even help ?!

Indeed, the patch doesn't seem to address the bug as reported (which I don't think is a big issue). However, I did misinterpret it. The intention is to show a notification if network manager (rather than the user) requests a password. The notification will let you trigger the system modal to provide the secret.

I'm in two minds about this. Spontaneously triggering a system modal authentication dialog is clearly not nice. But then, network manager shouldn't be requesting passwords if the user hasn't explicitly tried to connect to something.

A notification could create some interaction issues. What if I miss the notification and try to manually reconnect? Do we remove the notification from the tray? It might be better to simply let the network connection fail silently, and perhaps prompt the user to reconnect if they try to do something that requires network access.
Comment 19 el 2012-06-27 17:30:15 UTC
(In reply to comment #18)
> A notification could create some interaction issues. What if I miss the
> notification and try to manually reconnect? Do we remove the notification from
> the tray? It might be better to simply let the network connection fail
> silently, and perhaps prompt the user to reconnect if they try to do something
> that requires network access.

Silently fail as in user needs to click wifi icon and manually click on the network to force a retry (which would then cause a password prompt)? I would absolutely hate that - in crowded university lectures, it is common for the wifi connection to be shaky due to too many users, and it would be pretty stupid if I had to manually initiate a reconnect constantly because network manager secretly fails and waits for me to do something to make it try again.
Comment 20 Allan Day 2012-06-27 18:16:11 UTC
(In reply to comment #19)
...
> and it would be pretty
> stupid if I had to manually initiate a reconnect constantly because network
> manager secretly fails and waits for me to do something to make it try again.

This is only in the case where you are required to input a password. I'm simply suggesting that you only get prompted to take action when you to try to do something that requires network access, rather than at the moment network manager discovers that it needs a password (which would be pretty disruptive).

Also, I'd advise against using words like 'hate' and 'stupid' when discussing design issues. It's unhelpful.
Comment 21 el 2012-06-27 18:20:44 UTC
What would be an action that requires network access? I like to be online in Jabber, does that count as such an action? Otherwise I'd need to take manual explicit actions to be online with Empathy/Jabber as much as the shaky conneciton allows - not exactly a good solution IMHO.
Comment 22 Giovanni Campagna 2012-10-22 19:46:35 UTC
*** Bug 686566 has been marked as a duplicate of this bug. ***
Comment 23 Milan Bouchet-Valat 2013-03-01 14:22:20 UTC
*** Bug 694933 has been marked as a duplicate of this bug. ***
Comment 24 Milan Bouchet-Valat 2013-03-01 14:23:54 UTC
(In reply to comment #20)
> This is only in the case where you are required to input a password. I'm simply
> suggesting that you only get prompted to take action when you to try to do
> something that requires network access, rather than at the moment network
> manager discovers that it needs a password (which would be pretty disruptive).
Allan, I don't think it is technically possible currently to detect that the user initiated an action that requires network, and present a password dialog only at that point. I also think that the connection attempt will abort after a timeout if NetworkManager withholds the authentication.


So the problematic use case is: you try to connect, enter a password that turns out to be wrong a few seconds later (can always happen). At that point, you suggested to make the connection fail silently instead of showing a modal password dialog as is currently done. I think it would not be a very nice user experience, because there would be no feedback on why the connection attempt did not succeed. It would be better to show a notification saying e.g. "Could not connect: wrong password", with a "Retry using another password" button. The user could then ignore the notification if he no longer cares. What do you think?
Comment 25 Jasper St. Pierre (not reading bugmail) 2013-03-01 17:27:14 UTC
I think we should keep the modal dialog up until the entire operation succeeds, and simply show a basic information message if it's not the correct password.

A lot of my issues with the current implementation are it going away and coming back.
Comment 26 Colin Walters 2013-03-01 17:36:44 UTC
I still think all user interaction should be done inside control-center, like how iOS does it.  If I close control-center's networking page, that is cancelling any connections, and no dialogs should pop up.
Comment 27 Davi 2013-08-24 11:53:56 UTC
There is this use case that supports showing a notification before popping up a dialog:

I am in the middle of an activity that requires continuously high concentration (e.g. programming or reading a complex paper). Then, for some reason the wifi connection restarts, then the dialog pops up and requests my full attention. For some reason, sometimes the dialog shows despite the password being saved and correct, and even multiple times. That totally disrupts the workflow and perhaps I didn't even care about being connected that much.

Is that too much of a corner case? It happens often when I'm at the lab in the university and lots of people share the same access point.
Comment 28 André Klapper 2013-08-31 13:12:46 UTC
Duplicate of bug 688434?
Comment 29 el 2013-08-31 23:39:48 UTC
It is, and I suppose more duplicates will pop up over the years as long as this isn't resolved.
Comment 30 Giovanni Campagna 2013-09-04 21:49:09 UTC
*** Bug 707502 has been marked as a duplicate of this bug. ***
Comment 31 Milan Bouchet-Valat 2013-10-04 15:59:33 UTC
*** Bug 709430 has been marked as a duplicate of this bug. ***
Comment 32 Daniel Preston 2013-11-21 17:05:24 UTC
What about at least marking it confirmed (new)?
Comment 33 Frederic Peters 2013-11-21 17:24:42 UTC
(In reply to comment #32)
> What about at least marking it confirmed (new)?

We generally don't use the 'NEW' state in GNOME bugzilla.
Comment 34 Giovanni Campagna 2014-01-04 16:44:16 UTC
*** Bug 693674 has been marked as a duplicate of this bug. ***
Comment 35 Bastien Nocera 2014-11-07 09:28:21 UTC
*** Bug 688434 has been marked as a duplicate of this bug. ***
Comment 36 Bastien Nocera 2014-11-07 09:28:47 UTC
*** Bug 729197 has been marked as a duplicate of this bug. ***
Comment 37 Paul Smith 2014-11-07 15:07:09 UTC
Please undo the closed/duplicate for bug 688434.  That bug is not a duplicate of this one: that bug talks about modal password dialogs in general and has lots of good information about use-cases and possible alternatives; this one is specifically about NetworkManager.  I don't care much about NetworkManager but I care a lot about OTHER apps that also need to request passwords, many of which do it completely asynchronously so there's no opportunity to copy a password first.

This feature is really disastrous from a usability standpoint.
Comment 38 Lukas Pirl 2014-11-07 16:08:18 UTC
(In reply to comment #37)
Definitely.
Comment 39 Johannes Rohr 2014-11-10 00:28:55 UTC
(In reply to comment #37)
> Please undo the closed/duplicate for bug 688434.  That bug is not a duplicate
> of this one: that bug talks about modal password dialogs in general and has
> lots of good information about use-cases and possible alternatives; this one is
> specifically about NetworkManager.  I don't care much about NetworkManager but
> I care a lot about OTHER apps that also need to request passwords, many of
> which do it completely asynchronously so there's no opportunity to copy a
> password first.
> 
> This feature is really disastrous from a usability standpoint.

I agree. I think most of the annoying modal password prompts I have seen pop up unexpectedly are triggered by Evolution, whenever it has difficulties connecting to a resource. One of the many problems with these prompts, is that they provide insufficient information about for which resource or account the password is being requested. Overall, this is a usability mess and needs to be fixed.
Comment 40 Dan Winship 2014-11-26 13:10:23 UTC
*** Bug 740746 has been marked as a duplicate of this bug. ***
Comment 41 André Klapper 2015-02-22 21:12:56 UTC
Patch status accepted-commit-now was set in 2012, and the other patch is still unreviewed.
How to get some progress here?
Comment 42 Giovanni Campagna 2015-03-04 01:03:49 UTC
Created attachment 298496 [details] [review]
NetworkAgent: differentiate between user-initiated actions and automatic connections

If the action was initiated by the user, we want to show the
modal dialog immediately, while if the action was initiated by
NM autoconnection policy we first show a notification and then
show the dialog when needed.

Rebased and adapted to the new message tray code. It is now
up to the designers to make their mind and ack or reject this
patch.
Comment 43 Matthias Clasen 2015-03-04 11:50:14 UTC
getting this in for 3.16 would be really nice
Comment 44 drago01 2015-03-04 12:03:03 UTC
Review of attachment 298496 [details] [review]:

Code looks good to me ... just one fix should be in its own patch.

::: js/ui/components/networkAgent.js
@@ +341,3 @@
                 content.secrets.push({ label: _("PIN: "), key: 'pin',
                                        value: gsmSetting.pin || '', password: true });
+                break;

Unrelated (but correct) change ... should be a separate patch.
Comment 45 Jakub Steiner 2015-03-04 12:20:46 UTC
Granted I haven't tested this, specifically the more complex scenarios Allan is worried about, offloading non-user auth requests to notifications seems like a reasonable solution.
Comment 46 Florian Müllner 2015-03-11 18:08:38 UTC
*** Bug 740750 has been marked as a duplicate of this bug. ***
Comment 47 Giovanni Campagna 2015-03-11 20:41:55 UTC
I wasn't sure Jakub's comment was a full ack, but in that case I'll send the email to the release-team.
Comment 48 Florian Müllner 2015-03-11 20:43:53 UTC
Thanks!
Comment 49 Giovanni Campagna 2015-03-12 20:34:08 UTC
Approved by the release-team.

Attachment 298496 [details] pushed as 90a08ba - NetworkAgent: differentiate between user-initiated actions and automatic connections
Comment 50 Allan Day 2015-03-12 21:00:03 UTC
Woo hoo! Thanks Giovanni! :)