Created attachment 8641300 [details] proposal.gif See attached gif. It could help users identify which forms inputs were filled in the current page.
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).
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.
Component: Form Manager → Password Manager
We could use rfeeley's input on this one!
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.
Flags: needinfo?(rfeeley) → needinfo?(shorlander)
(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.
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
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.
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. :)
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?
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?
Flags: needinfo?(MattN+bmo) → needinfo?(shorlander)
(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.
You need to log in before you can comment on or make changes to this bug.