Open Bug 1149505 Opened 9 years ago Updated 10 months ago

Master password prompt shouldn't be modal unless absolutely necessary

Categories

(Firefox :: Security, defect)

38 Branch
x86
All
defect

Tracking

()

People

(Reporter: phlsa, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [qx][ux-qx])

Attachments

(2 files)

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.
See Also: → 460868
Mistakenly filed against Firefox 38 and should be instead 38 Branch. Sorry for the spam. dkl
Version: Firefox 38 → 38 Branch
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.

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

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.

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.

Severity: normal → S3

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.

Flags: needinfo?(sgalich)

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.

Flags: needinfo?(sgalich)
See Also: → 1768856
Duplicate of this bug: 1711021
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: