Closed
Bug 1320401
Opened 8 years ago
Closed 8 years ago
Can not dismiss password doorhanger by clicking elsewhere within window
Categories
(Firefox :: Site Identity, defect, P1)
Tracking
()
VERIFIED
FIXED
Firefox 53
Tracking | Status | |
---|---|---|
firefox50 | --- | unaffected |
firefox51 | --- | unaffected |
firefox52 | --- | unaffected |
firefox53 | --- | verified |
firefox54 | --- | verified |
People
(Reporter: ueguimmeo, Assigned: johannh)
References
Details
(Keywords: regression, Whiteboard: [fxprivacy] )
Attachments
(1 file)
i see in nightly 53 the doorhanger has to be addressed directly by the user. this is very intrusive and there should be a way to turn off the new requirement that the user interact directly with the doorhanger. for example, a user might not want to save a password for a site because they don't want a record of that site saved in the browser. selecting "never for this site" defeats that purpose. requiring the user to interact directly with the doorhanger rather than passively by clicking elsewhere within the window creates friction in user experience. another use case: you're logging-in on a shared computer and don't want your password saved, but another user does want their password saved. in this case, "never for this site" is not an option, forcing user to more directly dismiss the doorhanger every time they log-in. another use case against this: some sites do tricks like altering the content of the credential fields when the user submits, apparently with the intention of preventing the user from saving their credentials. firefox makes it easy to work around this and save the correct credentials when the doorhanger comes up the first time, but even though firefox on later visits pre-fills the login form correctly, when user presses submit, the fields get changed, causing firefox to ask whether to save the "edited" credentials. this is annoying but not firefox's fault. i simply click elsewhere in the window to quickly dismiss the doorhanger, but in nightly 53 this is no longer possible and i have to directly interact with the doorhanger every time -- very annoying. take a look at the login form on fidelity.com as an example -- enter username "JohnSmith" and press tab ... the username gets switched to "*****mith" these are just some examples i came up with off the top of my head. if you think it's a great default to force direct interaction with hanger, that's one thing, but there are legitimate reasons a user might want to disable that requirement, so please make it optional!
a couple more use cases i ran into today ... sites that require you to re-type your password to get to a more secure area, or to save edits to the site's profile -- firefox has always popped up the doorhanger for these, but now the user is forced to interact with it directly. sites with an edit profile page where the password field is pre-filled by the site but can be changed by the user, along with other details. the user may just change e.g. their address and click save, but since the password field appears on the page, firefox pops up the doorhanger, and since nightly 53 this is more intrusive.
Assignee | ||
Updated•8 years ago
|
Whiteboard: [fxprivacy] [triage]
Updated•8 years ago
|
Whiteboard: [fxprivacy] [triage] → [fxprivacy]
Comment 2•8 years ago
|
||
+Ryan/Philipp We need some direction here. We can chat about it next week in person.
Flags: needinfo?(rfeeley)
Flags: needinfo?(philipp)
Comment 3•8 years ago
|
||
(In reply to ueguimmeo from comment #0) > for example, a user might not want to save a password for a site because > they don't want a record of that site saved in the browser. selecting "never > for this site" defeats that purpose. requiring the user to interact directly > with the doorhanger rather than passively by clicking elsewhere within the > window creates friction in user experience. > In order to clear the site from history, a user may use multiple options 1) Be using private mode. * In private mode, we don't prompt to save a password 2) Set your browser to "Never Remember History" in about:preferences#privacy or select "Use custom settings for history" and check the "Always use private browsing mode" * Puts your browser in private mode, we don't prompt to save a password 3) Go to about:preferences#privacy and select "Use custom settings for history". Then uncheck the box for "Remember my browsing and download history" * Doesn't put your browser in private mode. We do show the password prompt and the user will have to click "Don't save" every single time in order to keep the site from being stored in their browsing data. 4) Go to a website, and then click "Clear Recent History...". * If you clear "Site Preferences", it will also clear the fact that you didn't want to save the password. * If you don't select "Site Preferences", it will not clear the fact that you didn't want to save the password. So the scenario where this is an privacy problem for users is scenario 3. I agree that in general the new way the password doorhanger works is annoying, and I ran into it in today's nightly before seeing this bug. Particularly because Password Manager is defaulted to on for users and most users probably don't go into preferences to disable it. They will have to interact with a doorhanger everytime they login to any site.
Comment 4•8 years ago
|
||
The point of removing the 'dismiss when clicking elsewhere' behavior was to avoid making websites wait forever for an answer from the user. In the case of the password manager panel, the website isn't waiting, so maybe we don't need to make this panel persistent at all? (I mean, it's possible we don't need to add an option for this, and could just revert the behavior for the password manager panel specifically).
Comment 5•8 years ago
|
||
Perhaps because this is different to permissions it might better belong as part of the global doorhanger I suggested: https://bugzilla.mozilla.org/show_bug.cgi?id=1319984
Assignee | ||
Updated•8 years ago
|
Summary: option to dismiss doorhanger by clicking elsewhere within window (like before nightly 53) → Can not dismiss password doorhanger by clicking elsewhere within window
Assignee | ||
Updated•8 years ago
|
status-firefox50:
--- → unaffected
status-firefox51:
--- → unaffected
status-firefox52:
--- → unaffected
status-firefox53:
--- → affected
Keywords: regression
Priority: -- → P1
Comment 7•8 years ago
|
||
I will add that users often accidentally close the door hanger by clicking elsewhere and in user testing passwords, zero of them recognized the key icon as a way to bring back the door hanger.
Flags: needinfo?(rfeeley)
Comment 8•8 years ago
|
||
Relevant, and recent from our user research team: https://medium.com/firefox-ux/user-study-new-privacy-permissions-panel-223e61cc7545#.r2n8r63b2
Assignee | ||
Comment 9•8 years ago
|
||
(In reply to Ryan Feeley [:rfeeley] from comment #7) > I will add that users often accidentally close the door hanger by clicking > elsewhere and in user testing passwords, zero of them recognized the key > icon as a way to bring back the door hanger. Does that mean you think we should keep the current behavior? There are quite a lot of people inside and outside the team who are opposed to this. I think the comments in this bug make good points, the password prompt is very intrusive right now and forcing users to interact with the password doorhanger does not benefit web developers. Ryan or Philipp, can you please respond to these points if you think we should keep the current behavior anyway? This needs to be decided before the 53 merge.
Flags: needinfo?(rfeeley)
Reporter | ||
Comment 10•8 years ago
|
||
i don't see the case that a user accidentally dismisses the doorhanger as being a big deal, as it will simply be presented again the next time the user logs in. if for some reason it's decided that the default behavior needs to be the more intrusive doorhanger, please add an about:config setting to override.
Comment 11•8 years ago
|
||
I'll make the call as everyone is away. Let's go with the less intrusive version, as you are right, web developers are likely less likely to support the intrusive version than they are for a geo-location permission. Perhaps if the negative option was "never save" it would make more sense, but it doesn't, and will intrude every time.
Flags: needinfo?(rfeeley)
Flags: needinfo?(philipp)
Comment hidden (mozreview-request) |
Assignee | ||
Comment 14•8 years ago
|
||
https://treeherder.mozilla.org/#/jobs?repo=try&revision=155f46b7c7a0
Comment 15•8 years ago
|
||
mozreview-review |
Comment on attachment 8823624 [details] Bug 1320401 - Make the password doorhanger non-persistent again. https://reviewboard.mozilla.org/r/102158/#review102472 ::: toolkit/components/passwordmgr/nsLoginManagerPrompter.js (Diff revision 1) > "password-notification-icon", > mainAction, > secondaryActions, > { > persistWhileVisible: true, > - persistent: true, Do we need to re-add the timeout? https://hg.mozilla.org/integration/mozilla-inbound/rev/33ea134bf627#l13.1
Comment hidden (mozreview-request) |
Comment 18•8 years ago
|
||
mozreview-review |
Comment on attachment 8823624 [details] Bug 1320401 - Make the password doorhanger non-persistent again. https://reviewboard.mozilla.org/r/102158/#review102504 Looks good, and it's a straight revert of the changes we did to this file in bug 1004061. Thanks!
Attachment #8823624 -
Flags: review?(florian) → review+
Comment 19•8 years ago
|
||
Pushed by jhofmann@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/6f37882e28da Make the password doorhanger non-persistent again. r=florian
Comment 20•8 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/6f37882e28da
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 53
Comment 21•8 years ago
|
||
Build ID: 20170207030214 User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:54.0) Gecko/20100101 Firefox/54.0 Verified as fixed on on Windows 10 x 64, Mac OS X 10.11 and Ubuntu 16.04 x64 on Firefox Nightly 54.0a1, Firefox Nightly 53.0a1 and Aurora 53.0a2.
You need to log in
before you can comment on or make changes to this bug.
Description
•