Can not dismiss password doorhanger by clicking elsewhere within window

VERIFIED FIXED in Firefox 53

Status

()

Firefox
Site Identity and Permission Panels
P1
normal
VERIFIED FIXED
a year ago
10 months ago

People

(Reporter: ueguimmeo, Assigned: johannh)

Tracking

({regression})

53 Branch
Firefox 53
regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox50 unaffected, firefox51 unaffected, firefox52 unaffected, firefox53 verified, firefox54 verified)

Details

(Whiteboard: [fxprivacy] )

MozReview Requests

()

Submitter Diff Changes Open Issues Last Updated
Loading...
Error loading review requests:

Attachments

(1 attachment)

(Reporter)

Description

a year ago
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!

Updated

a year ago
Component: Untriaged → Site Identity and Permission Panels

Updated

a year ago
Blocks: 1282768
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 1

a year ago
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

a year ago
Whiteboard: [fxprivacy] [triage]
Whiteboard: [fxprivacy] [triage] → [fxprivacy]
+Ryan/Philipp

We need some direction here.  
We can chat about it next week in person.
Flags: needinfo?(rfeeley)
Flags: needinfo?(philipp)

Comment 3

a year 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.
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).
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

Updated

a year ago
Depends on: 1319176
(Assignee)

Updated

11 months ago
Duplicate of this bug: 1324301
(Assignee)

Updated

11 months 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

11 months ago
status-firefox50: --- → unaffected
status-firefox51: --- → unaffected
status-firefox52: --- → unaffected
status-firefox53: --- → affected
Keywords: regression
Priority: -- → P1

Comment 7

11 months 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

11 months 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

11 months 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

11 months 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

11 months 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)
(Assignee)

Comment 12

11 months ago
Thanks! :)
Assignee: nobody → jhofmann
Status: NEW → ASSIGNED
Comment hidden (mozreview-request)
(Assignee)

Comment 14

11 months ago
https://treeherder.mozilla.org/#/jobs?repo=try&revision=155f46b7c7a0

Comment 15

11 months 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
(Assignee)

Comment 16

11 months ago
Good catch!
Comment hidden (mozreview-request)

Comment 18

11 months 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

11 months 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

11 months ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/6f37882e28da
Status: ASSIGNED → RESOLVED
Last Resolved: 11 months ago
status-firefox53: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 53

Comment 21

10 months 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.
Status: RESOLVED → VERIFIED
status-firefox53: fixed → verified
status-firefox54: --- → verified
You need to log in before you can comment on or make changes to this bug.