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.

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.

(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.

(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.

A shell notification seems good for now.

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)

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.

*** Bug 677541 has been marked as a duplicate of this bug. ***

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 ;

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.

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.

(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.

(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?

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.

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.

(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.

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 ?!

(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.

(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.

(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.

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.

*** Bug 686566 has been marked as a duplicate of this bug. ***

*** Bug 694933 has been marked as a duplicate of this bug. ***

(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?

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.

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.

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.

Duplicate of bug 688434?

It is, and I suppose more duplicates will pop up over the years as long as this isn't resolved.

*** Bug 707502 has been marked as a duplicate of this bug. ***

*** Bug 709430 has been marked as a duplicate of this bug. ***

What about at least marking it confirmed (new)?

(In reply to comment #32)
> What about at least marking it confirmed (new)?

We generally don't use the 'NEW' state in GNOME bugzilla.

*** Bug 693674 has been marked as a duplicate of this bug. ***

*** Bug 688434 has been marked as a duplicate of this bug. ***

*** Bug 729197 has been marked as a duplicate of this bug. ***

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.

(In reply to comment #37)
Definitely.

(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.

*** Bug 740746 has been marked as a duplicate of this bug. ***

Patch status accepted-commit-now was set in 2012, and the other patch is still unreviewed.
How to get some progress here?

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.

getting this in for 3.16 would be really nice

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.

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.

*** Bug 740750 has been marked as a duplicate of this bug. ***

I wasn't sure Jakub's comment was a full ack, but in that case I'll send the email to the release-team.

Thanks!

Approved by the release-team.

Attachment 298496 [details] pushed as 90a08ba - NetworkAgent: differentiate between user-initiated actions and automatic connections

Woo hoo! Thanks Giovanni! :)