Provide visual feedback to the user when login fields were autofilled
Categories
(Toolkit :: Password Manager, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox67 | --- | fixed |
People
(Reporter: eoger, Assigned: prathiksha)
References
(Depends on 3 open bugs, Blocks 1 open bug)
Details
(Whiteboard: [passwords:fill-ui] )
Attachments
(3 files)
See attached gif. It could help users identify which forms inputs were filled in the current page.
Comment 1•9 years ago
|
||
This would probably be a nice visual indication of the inputs filled by the password manager context menu form fill (bug 433238) or the fill doorhanger (bug 1129528).
Comment 2•9 years ago
|
||
Styling the inputs in the content area can be quite fragile so we've been avoiding it so far. Of course that doesn't mean we can't try it.
Comment 4•9 years ago
|
||
It's a good idea, and one I've been thinking about too. A little animation might help the user understand that we’re doing something for them. 1Password doesn't use colour but merely pops the text a little. I'm going to needinfo from shorlander on this as he may have something for us.
Comment 5•9 years ago
|
||
(In reply to Ryan Feeley from comment #4) > Created attachment 8643100 [details] > fill-animation.gif > > It's a good idea, and one I've been thinking about too. A little animation > might help the user understand that we’re doing something for them. > 1Password doesn't use colour but merely pops the text a little. I'm going to > needinfo from shorlander on this as he may have something for us. I like the bounce. Feels like something is being plopped there.
Comment 6•9 years ago
|
||
I spoke with Stephen and the team about this. They felt strongly that the yellow should persist. I came up with this based on their feedback. What do you think? Colour is #FFFF9B. http://people.mozilla.org/~rfeeley/images/golden.gif
Comment 7•9 years ago
|
||
I'm pretty sure ckarlof suggested we avoid modifying the page as he had bad experiences doing that in the past. I think it's much less likely that an animation interferes with the page than changing colours so I'd rather we only do an animation if we're doing this. Also, if the page is doing something unusual, there will only be a problem during the animation duration whereas a colour/style clash will continue to be a problem. For example: consider a page with a dark theme where the text (bullet) colour is yellow (maybe on black), I'm assuming we don't want yellow-on-yellow with this suggestion but ideally this would be a CSS-only change and CSS can't do different things based on the computed colours.
Comment 8•9 years ago
|
||
Indeed, I would avoid styling the page in any way because the worst case failure cases can be bad. "Overlays" are less bad, but depending on how styled they are, they can also visually clash in unexpected ways with the page. The autocomplete UI is IMO, a good demonstration of how to be conservative. It's so simple that it's unlikely clash. It ain't much to look at, either, though. :)
Reporter | ||
Updated•9 years ago
|
Comment 9•9 years ago
|
||
MattN: I think that a color like hsla(58,100%,50%,0.33) would work on most backgrounds (except yellow). I do worry about the performance impact of an animation (now with reduced opacity). Thoughts?
Comment 10•8 years ago
|
||
I noticed how you animate in focus in your awesomebar mockups. Do you imagine this treatment would also be relevant for when we autofill fields like username, password and beyond?
Comment 11•8 years ago
|
||
(In reply to Ryan Feeley [:rfeeley] from comment #10) > I noticed how you animate in focus in your awesomebar mockups. Do you > imagine this treatment would also be relevant for when we autofill fields > like username, password and beyond? That was specifically to mimic the native focus behavior. I think whatever we do to incontent forms would have to be flexible enough to handle whatever styling the site has.
Comment 12•5 years ago
|
||
We now have the APIs for this since we implemented them for Form Autofill.
Comment 13•5 years ago
|
||
We're going to use the existing visual treatment that Form Autofill uses as well.
See code at https://searchfox.org/mozilla-central/search?q=_changeFieldState&case=false®exp=false&path= and FIELD_STATES.AUTO_FILLED.
We would need event listeners to clear the highlight when it's changed like Form Autofill does.
Comment 14•5 years ago
|
||
We should change the colour with setUserInput: https://searchfox.org/mozilla-central/rev/465dbfe030dfec7756b9b523029e90d48dd5ecce/toolkit/components/passwordmgr/LoginManagerContent.jsm#1236,1242
and add an input
listener to clear the colour when edited (like form autofill does).
Assignee | ||
Comment 15•5 years ago
|
||
Provide visual feedback to the user when login fields are autofilled.
Updated•5 years ago
|
Comment 17•5 years ago
|
||
Pushed by mozilla@noorenberghe.ca: https://hg.mozilla.org/integration/mozilla-inbound/rev/bcfe1e75c501 Provide visual feedback to the user when login fields are autofilled and autocompleted. r=MattN
Comment 18•5 years ago
|
||
bugherder |
Comment 19•5 years ago
|
||
How can users re-style or disable this feature if they don't like it? A rule for the yellow highlighting doesn't show up in the element inspector at all as far as I can see. Is it really hard-coded?
Comment 20•5 years ago
|
||
I tried setting background-color:white !important in the element inspector and it had no effect. I found a post advising that setting signon.showAutoCompleteFooter to false would disable this, but it doesn't. I find it really annoying and would like to be able to turn it off. There should be a config setting to allow users to turn it off if they wish.
Comment 21•5 years ago
|
||
This new modification does not make sense. It ruins the site that I am developing. You should give the option to disable the yellow background color. Could you do a rollback for this? Thank you!
Comment 22•5 years ago
|
||
This feature has landed and this bug is resolved/fixed, so not a good place for ongoing discussion. If you encounter problems with the autofill highlight/background field color please file a new bug under the Toolkit:Password Manager component with as much detail as you can manage:, including the nature of the problem, when/where it occurs, what you would expect vs. actual behavior.
Comment 23•5 years ago
|
||
I found a solution with css:
input { filter: none !important; }
That is all!!
Description
•