Master password prompt shouldn't be modal unless absolutely necessary
Categories
(Firefox :: Security, defect)
Tracking
()
People
(Reporter: phlsa, Unassigned)
References
(Blocks 1 open bug)
Details
(Whiteboard: [qx][ux-qx])
Attachments
(2 files)
Updated•10 years ago
|
Comment 1•10 years ago
|
||
Comment hidden (me-too) |
Updated•9 years ago
|
Comment 4•9 years ago
|
||
Comment 5•9 years ago
|
||
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•4 years ago
|
||
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•4 years ago
|
||
Comment 12•2 years ago
|
||
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.
Updated•2 years ago
|
Comment 13•2 years ago
|
||
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•2 years ago
|
||
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.
Updated•2 years ago
|
Description
•