1149505 - Master password prompt shouldn't be modal unless absolutely necessary

Status: NEW

(Toolkit :: Password Manager, defect, P3)

Description

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

The current master password prompt is always a modal dialog. This is particularly unpleasant when a tab that requires a password loads in the background and the user is faced with the (equally unpleasant, bug 306730) prompt message in the middle of something else.

I understand that there might be situations where blocking is unavoidable (what are those situations?) but unless the user runs into such a situation, we should find a different kind of prompt.

Comment 1

[David Lawrence [:dkl]]

Mistakenly filed against Firefox 38 and should be instead 38 Branch. Sorry for the spam. dkl

Comment 2

[cumu]

Please take account of this issue as it is very annoying ! Thank you :)

Comment 4

[Jean-François T]

Attachment: Suggestion for a new master password prompt dialog

Comment 5

[Jean-François T]

I confirm the current prompt dialog is unpleasant.
I have added a suggestion for a new master password prompt in the previous attachment.
Plus it has the advantage to be displayed only on the pages that contain password fields.

Comment 9

[Mentat]

I made very simple addon for switch on/off password saving option (if password saving is off there is no prompt for master password).
https://addons.mozilla.org/pl/firefox/addon/password-saving-switch

Comment 10

[u548634]

I just wanted to open a new bug until I found this. This issue has also bothered me for a long time.

I use pinned tabs and the option to restore the last session on startup. So when I start Firefox, I always get a modal prompt that blocks the whole window, because I have an account on some website in a background/pinned tab.

In my opinion this is a bug for several reasons:

• It shows a blocking modal prompt right at startup before any interaction has took place. This is just bad UX. It should wait to present the prompt until it is contextually relevant to the user.
• If the tab/website is in the background, there is no reason for the prompt to be there in the first place. Why would it block the whole Firefox window, not just the tab/website it is from?

I am using the Nightly version and recently tried out the new printing modal via print.tab_modal.enabled. I really like that it appears above the page as an embedded window and only blocks the current tab. Could you do someting similar for the master password promt?

On a related note, I would also argue that the user might not want to log into a website in the first place, even if they interact with it. Maybe the prompt could appear once the user interacts with/clicks on the username/password inputs? I've also wondered whether websites could use Javascript to read pre filled-in form data for tracking purposes. For example the user name field to track users even when they specifically didn't log in this time. Another reason why it might make sense to ask for the master password "lazily" once it is required and even fill in data only once the user clicks on the input fields. But this is probably a seperate issue.

Comment 11

[u548634]

Attachment: Master-password-modal-mockup.png

Comment 12

[Steve Fink [:sfink] [:s:]]

It seems to me that this is at least somewhat a security issue as well. At least on Linux, the master password modal often shows up in the middle of a content window, which means it's spoofable (and I am now well trained to type in my master password whenever the window shows up, because otherwise things mysteriously don't work until I do).

I'm ok with it being blocking, but I'd prefer a doorhanger (pointing into the chrome area) repeated on every window.

Comment 13

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 4 duplicates.
:serg, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 14

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Comment 16

[Markus Keller]

See also bug 1714215 and bug 101611.

Comment 17

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:mtigley, could you have a look please?

For more information, please visit BugBot documentation.

Comment 18

[Revertron]

(In reply to u548634 from comment #10)

All of this is still relevant an very frustrating. The password prompt just prevents all pinned tabs from loading, as if the browser froze.
And even more - those tabs have no password fields.

I just wanted to open a new bug until I found this. This issue has also bothered me for a long time.

I use pinned tabs and the option to restore the last session on startup. So when I start Firefox, I always get a modal prompt that blocks the whole window, because I have an account on some website in a background/pinned tab.

In my opinion this is a bug for several reasons:

• It shows a blocking modal prompt right at startup before any interaction has took place. This is just bad UX. It should wait to present the prompt until it is contextually relevant to the user.
• If the tab/website is in the background, there is no reason for the prompt to be there in the first place. Why would it block the whole Firefox window, not just the tab/website it is from?

I am using the Nightly version and recently tried out the new printing modal via print.tab_modal.enabled. I really like that it appears above the page as an embedded window and only blocks the current tab. Could you do someting similar for the master password promt?

On a related note, I would also argue that the user might not want to log into a website in the first place, even if they interact with it. Maybe the prompt could appear once the user interacts with/clicks on the username/password inputs? I've also wondered whether websites could use Javascript to read pre filled-in form data for tracking purposes. For example the user name field to track users even when they specifically didn't log in this time. Another reason why it might make sense to ask for the master password "lazily" once it is required and even fill in data only once the user clicks on the input fields. But this is probably a seperate issue.

Comment 19

[Kevin Brubeck Unhammer]

It's also an issue with multiple desktops. The master password prompt may show on a different desktop than the one you're on, and when you try to log in to a new site, the password field behave as if you have zero stored passwords (since you haven't yet entered the master password because the prompt is on a different desktop). This is very confusing. I think ideally there would be some kind of "box"/notification fixed to the top of each browser window until the master password is entered (or at least for those windows where password info is asked for).