GNOME Bugzilla – Bug 727149
Odd looking password dialog
Last modified: 2014-10-03 19:32:12 UTC
Created attachment 273075 [details] screenshot When I was working on the 3.12 release notes, the page was password protected, and the dialog I got in epiphany looked really bad. * The dialog is far too wide, with too much space between the labels and the entry fields. * The entry fields are too wide. * The "OK" button should have a more meaningful label, like "Authenticate" or "Unlock". * It doesn't have a heading. * The first line reads awkwardly: it is in the wrong tense. Perhaps "Username and password required" would be better.
I'm wonder if this dialog came from seahorse or gnome-keyring or something like this, because I not see any for thes strings in the screenshot in my he.po (btw, looking into .po file for find the place in the code of something is very good way).
The dialog is in webkit. I don't see it that wide, though. what's the url of the release notes?
(In reply to comment #2) > The dialog is in webkit. I don't see it that wide, though. what's the url of > the release notes? The password protection has been taken off them now. You could ask one of the sysadmins to set up a test page for you, perhaps...
An example can be seen at https://www.httpwatch.com/httpgallery/authentication/, by clicking the Display Image button.
(In reply to comment #2) > The dialog is in webkit. I don't see it that wide, though. what's the url of > the release notes? Yes, the dialog is from webkit indeed, Source/WebCore/platform/gtk/WebKitAuthenticationWidget.cpp I guess you didn't see it that wide, because it also contains the Server Message, which in your case was a shorter string, but in case of the release notes or the provided example it's a longer string, which seems to make the dialog wider. I guess this could be worked around by providing a custom authentication dialog, and handling the WebKitWebView's authenticate signal to pop the new dialog up, that way we would have full control on how to show the authentication dialog.
No, please, let's fix it in webkit, we don't need any workaround in ephy.
Allan, please let me know if the screenshot at https://bugs.webkit.org/show_bug.cgi?id=136615 looks good to you.
Created attachment 285639 [details] mockup (In reply to comment #7) > Allan, please let me know if the screenshot at > https://bugs.webkit.org/show_bug.cgi?id=136615 looks good to you. Much better! Thanks for working on this Michael. A few possible improvements: * "<site> allows only authorized users to continue." seems slightly awkward to me. The following seems simpler and more direct: "Authorization is required by <site>." * "It says" seems a bit informal. It would also be nice to start the server message on a new line - to make it easier to pick out, and the cognitive overhead of identifying the message text. * The username and password fields seem a little on the wide side. * The "Authenticate" button should be insensitive until the username and password have been filled in. Mockup attached.
Thanks Allan! (In reply to comment #8) > Created an attachment (id=285639) [details] > * "It says" seems a bit informal. It would also be nice to start the server > message on a new line - to make it easier to pick out, and the cognitive > overhead of identifying the message text. I agree this is poor, but I was trying to distinguish the server's message from the operating system without using the word "server." Your mockup looks good, but now replace the server message with "This is the same as your PayPal password" -- hopefully users won't trust this, but it looks like an operating system dialog, so maybe it's legit? Also, some servers send very short messages, like simply "Auth" or something that looks like an email address, which might look weird on its own line without any context. But these are probably minor concerns, so I think I'll implement your mockup anyway; I just want you to consider if there might be a good way to distinguish the server message from the rest of the dialog. (In reply to comment #8) > * The "Authenticate" button should be insensitive until the username and > password have been filled in. The password can definitely be empty. [1] is a little ambiguous, but my reading is that usernames can be too, weird as that seems. It looks like Chrome and Firefox and Safari all permit both to be empty, so we probably should too. [1] http://www.ietf.org/rfc/rfc2617.txt
(In reply to comment #8) > Mockup attached. I posted an updated screenshot in the webkit bug. The rounded corners are giving me a lot of trouble, but the rest seems fairly close to what you have.
I'm going to go ahead and close this. About half the changes from your mockup made it into 2.6; we didn't want to make string changes, so the rest are sitting in https://bugs.webkit.org/show_bug.cgi?id=136782