UX issues with the http basic auth dialog

[allo-]

I wanted to add them to #377 but the list got a bit extensive.

Here some first impressions from a user new to the dialog. Nothing absolute, but some feedback on what the first issues are that I encountered.

• (1) I cannot close the dialog with esc if I decide I do not want to login (I just don't want, I don't have the GPG password with me, or I want to use the Firefox password store)
• (2) The dialog also opens for sites where no password is stored.
• (3) On the flip side of my use-case in the other issue: Closing the dialog does show the Firefox dialog (with or without stored password)
• (4) The dialog seems not to allow for a one-off login without storing the password
• (5) The Add credentials dialog seems a bit unclear:
  • It has no username field, but shows an example for "password\nuser: username" in the textfield
  • The secret field cannot be edited
  • the filename looks prefilled (I think that should usually be the username field or domain/[username].gpg)
  • At least for me it doesn't show stars when entering the password
  • When I add credentials with filename "test.gpg" the dialog doesn't show the entry for the new credentials afterward (related to the filename suggestion not matching the usual pattern)
  • The added password is not commited to the git (is the pass script used or gpg directly?)

[max-baz]

1. Agree!
2. This makes sense because just like on normal pages, you might want to hit Backspace and find another entry that for whatever reason doesn't match the domain - next time it will be in the popup. Without this, users will be blocked to pick an existing entry that for whatever reason doesn't match the domain - which is possible on regular websites.
3. This is also expected, if you don't have credentials stored in your password store, then you must have a way to type them in by hand - so closing the browserpass detached popup should let the browser take the control back and present you with the option to enter those credentials.
4. Do you mean by one-off login that on page refresh you expect to be asked for credentials again? If so, in't this matching browser behavior when you enter credentials by other means, like manually - refreshing page after successful login doesn't present you with basic auth again?
5. Good points, thanks for sharing, I don't think that part got tested much in this particular flow!

[allo-]

Yes, 4) is related to 3). If I want to enter the credentials one time, I need to close the dialog and get the Firefox dialog. I suppose that is the case anyway if browserpass doesn't inject a login.

I think the (maybe hard to solve) issue is trying to display only the browserpass dialog or only the Firefox dialog depending on what the user wants to use and where passwords are available.
I wonder if it would be good to store in the browser storage if a user doesn't want to use the browserpass dialog for a certain site.

You're right that one cannot know if the user wants to skip the dialog or to search for a password that cannot automatically be associated with the site. So the best option would probably be to let the user store the choice. Maybe even the last chosen password entry could be stored, but I am not sure about workflows of, e.g., people having many different accounts on a single site.

[patgmiller]

(1) I cannot close the dialog with esc

I don't completely agree or disagree. I completely understand wanting to close the popup with a simple keystroke. However, there is already functionality which was added to keep the original (attached) popup from completely closing when the esc key is pressed because esc is also used to exit from the Add / Edit view. You would normally be able mouse click outside the popup and it closed, but that also doesn't work b/c the detached http auth popup is a full chrome window instead of a popup for a tab.

@allo- @maximbaz , I know that Cmd-W works to close the detached pop up, however I haven't played with it on my Windows or Linux OS recently, so I think the Ctrl+W works to close it, but I'm not certain. Regardless, I understand / advocate personal preference; @maximbaz were you thinking we would have it conditionally close the window with esc only when it is detached? I suppose that could be an option.

[allo-]

Alt+F4 also works, but, like Ctrl+W, it is dangerous. If you press Alt+F4 or Ctrl+W with the wrong window or tab focused, you may lose data. I think the reason why the typical UI uses Esc to close dialogs is because main windows don't close with it, and dialogs, which are usually less important, do.
Also, Esc is in a much more easily accessible position than the other shortcuts. In this use case, the goal is to quickly close an unwanted window and that should be fast

I wonder if the point about the search function when no entry is found is important, or if the HTTP-Auth window could appear only if there is an exact match. This would solve the issue for those who want to disable the window completely, and still allowing users to open it to search for credentials by pressing the toolbar button or hotkey.

I also wonder if HTTP authentication credentials should be marked in some way. There is also the issue that there can be an HTML form behind HTTP authentication that requires another password. For example, one might need "employee:internal-area-password" for HTTP authentication and "name@company:personal-password" for the login form of the protected web application.

[max-baz]

However, there is already functionality which was added to keep the original (attached) popup from completely closing when the esc key is pressed because esc is also used to exit from the Add / Edit view.

To be honest I wasn't even fully aware of this behavior 😅 I agree that Esc should exit first from the add / edit view, but once you are back in the main popup view, maybe here Esc should close the popup? This would also solve the Esc closing detached popup, when we are in the main view.

[allo-]

I think handling a hotkey first as backward step and then as closing would be a good solution. There are two possible places:

• Esc could get back from the add/edit view first and if that view is not open it could close the window
• Replace Esc in closing add/edit by hitting backspace when the form field is empty and use Esc to close the window (any time).

Having the window fully keyboard navigable is also important. It currently also feels very much not like native UI. Of course the non-native UI elements are one point, but I think mimicing layout, hotkeys, and general UI patterns that Firefox uses are more the problem than the exact shape of the buttons and the color scheme.