1320401 - Can not dismiss password doorhanger by clicking elsewhere within window

Status: VERIFIED FIXED

(Firefox :: Site Identity, defect, P1)

Description

[ueguimmeo]

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!

Comment 1

[ueguimmeo]

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.

Comment 2

[Peter Dolanjski [:pdol]]

+Ryan/Philipp

We need some direction here.  
We can chat about it next week in person.

Comment 3

[Tanvi Vyas[:tanvi]]

(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

[Florian Quèze [:florian]]

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

[Jonathan Kingston [:jkt] he/him]

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

Comment 7

[Ryan Feeley [:rfeeley]]

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.

Comment 8

[Ryan Feeley [:rfeeley]]

Relevant, and recent from our user research team: https://medium.com/firefox-ux/user-study-new-privacy-permissions-panel-223e61cc7545#.r2n8r63b2

Comment 9

[Johann Hofmann [:johannh]]

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

Comment 10

[ueguimmeo]

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

[Ryan Feeley [:rfeeley]]

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.

Comment 12

[Johann Hofmann [:johannh]]

Thanks! :)

Comment 13

[Johann Hofmann [:johannh]]

Attachment: Bug 1320401 - Make the password doorhanger non-persistent again.

Review commit: https://reviewboard.mozilla.org/r/102158/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/102158/

Comment 14

[Johann Hofmann [:johannh]]

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

Comment 15

[Florian Quèze [:florian]]

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 16

[Johann Hofmann [:johannh]]

Good catch!

Comment 17

[Johann Hofmann [:johannh]]

Comment on attachment 8823624 [details]
Bug 1320401 - Make the password doorhanger non-persistent again.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/102158/diff/1-2/

Comment 18

[Florian Quèze [:florian]]

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!

Comment 19

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/6f37882e28da
Make the password doorhanger non-persistent again. r=florian

Comment 20

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/6f37882e28da

Comment 21

[Hani Yacoub, Desktop QA]

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.