Add password manager autocomplete suggestion when a username element in clicked.

Add password manager autocomplete suggestion when a username element in clicked.

This adds a full credential selection whenever a username element is clicked. Previously, if a username element was filled by either the user or the password manager, the user would have to erase the entire field to see the full list of credentials the user has. Now the user can click on the field at any point to get a full list of accounts. However, if the user starts typing again, then inline autocomplete takes over.

BUG=341474
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=283383

[jww, 2014-02-14 19:42:04]

This is the credential selector that we've discussed in the password manager
meetings.

[Ilya Sherman, 2014-02-14 21:12:49]

Why are we removing inline autocomplete?  IMO that's complementary to showing a
popup, not competing with it.

[jww, 2014-02-14 21:30:48]

On 2014/02/14 21:12:49, Ilya Sherman wrote:
> Why are we removing inline autocomplete?  IMO that's complementary to showing
a
> popup, not competing with it.

The thinking is that it's more important to always show the full set of
credentials on a given site than to show any subset, otherwise users may get
confused about what credentials are available. Additionally, a flow where a
click on the username element reveals the full list would have very odd
interactions with inline autocomplete. For example, if Chrome autofills the
username and password on load, and then the user clicks on the username, should
it show a full list of credentials? It was decided that, yes, that's very
important, so the user can quickly see all accounts available to them. But what
happens if they erase a character? Should Chrome all of a sudden start inline
autocompleting? We thought that the best answer is that we should just show all
credentials at all time during autocomplete.

[Ilya Sherman, 2014-02-14 21:35:09]

On 2014/02/14 21:30:48, jww wrote:
> On 2014/02/14 21:12:49, Ilya Sherman wrote:
> > Why are we removing inline autocomplete?  IMO that's complementary to
showing
> a
> > popup, not competing with it.
> 
> The thinking is that it's more important to always show the full set of
> credentials on a given site than to show any subset, otherwise users may get
> confused about what credentials are available. Additionally, a flow where a
> click on the username element reveals the full list would have very odd
> interactions with inline autocomplete. For example, if Chrome autofills the
> username and password on load, and then the user clicks on the username,
should
> it show a full list of credentials? It was decided that, yes, that's very
> important, so the user can quickly see all accounts available to them. But
what
> happens if they erase a character? Should Chrome all of a sudden start inline
> autocompleting? We thought that the best answer is that we should just show
all
> credentials at all time during autocomplete.

Hmm, was this logic run past a UX designer?  I think filtering the list while
the user is typing makes sense.  What if I have 100 logins for a website
(because I am testing the website), and am trying to narrow down the list of
suggestions?

I also don't recall whether we ever offer inline autocomplete for sites where
the user has just a single username.  If so, I bet that's the most common use
case, so I'd hate to see us get worse in our handling of that case.

[jww, 2014-02-14 21:57:48]

On 2014/02/14 21:35:09, Ilya Sherman wrote:
> On 2014/02/14 21:30:48, jww wrote:
> > On 2014/02/14 21:12:49, Ilya Sherman wrote:
> > > Why are we removing inline autocomplete?  IMO that's complementary to
> showing
> > a
> > > popup, not competing with it.
> > 
> > The thinking is that it's more important to always show the full set of
> > credentials on a given site than to show any subset, otherwise users may get
> > confused about what credentials are available. Additionally, a flow where a
> > click on the username element reveals the full list would have very odd
> > interactions with inline autocomplete. For example, if Chrome autofills the
> > username and password on load, and then the user clicks on the username,
> should
> > it show a full list of credentials? It was decided that, yes, that's very
> > important, so the user can quickly see all accounts available to them. But
> what
> > happens if they erase a character? Should Chrome all of a sudden start
inline
> > autocompleting? We thought that the best answer is that we should just show
> all
> > credentials at all time during autocomplete.
> 
> Hmm, was this logic run past a UX designer?  I think filtering the list while
Rebecca (rolfe) was at the meeting where we discussed this, but it's a good idea
to loop her into this. I've CC'd her on this CL.
> the user is typing makes sense.  What if I have 100 logins for a website
> (because I am testing the website), and am trying to narrow down the list of
> suggestions?
I feel pretty strongly that we should be optimizing for the more common case of
two or three accounts, but this is a great question to loop a designer in on.
> 
> I also don't recall whether we ever offer inline autocomplete for sites where
> the user has just a single username.  If so, I bet that's the most common use
> case, so I'd hate to see us get worse in our handling of that case.
We do offer inline autocomplete for sites with a single username. But in those
cases, we're also autofilling on load, so I'm no sure there's a huge advantage
to inline autocomplete. That having been said, a middle ground that might make
sense is inline autocompleting the field itself, but to leave the full list
available. I don't love that approach, but I could be convinced.

The main issue that I care about is that the user can easily see the entire list
of credentials available. This, it turns out, is one of the main reasons web
sites use autocomplete='off', is that they expect multiple accounts to be used
on their site, and they don't want password managers confusing their users, so
we want to make this frictionless as possible.

[Ilya Sherman, 2014-02-14 23:27:00]

On 2014/02/14 21:57:48, jww wrote:
> On 2014/02/14 21:35:09, Ilya Sherman wrote:
> > On 2014/02/14 21:30:48, jww wrote:
> > > On 2014/02/14 21:12:49, Ilya Sherman wrote:
> > > > Why are we removing inline autocomplete?  IMO that's complementary to
> > showing
> > > a
> > > > popup, not competing with it.
> > > 
> > > The thinking is that it's more important to always show the full set of
> > > credentials on a given site than to show any subset, otherwise users may
get
> > > confused about what credentials are available. Additionally, a flow where
a
> > > click on the username element reveals the full list would have very odd
> > > interactions with inline autocomplete. For example, if Chrome autofills
the
> > > username and password on load, and then the user clicks on the username,
> > should
> > > it show a full list of credentials? It was decided that, yes, that's very
> > > important, so the user can quickly see all accounts available to them. But
> > what
> > > happens if they erase a character? Should Chrome all of a sudden start
> inline
> > > autocompleting? We thought that the best answer is that we should just
show
> > all
> > > credentials at all time during autocomplete.
> > 
> > Hmm, was this logic run past a UX designer?  I think filtering the list
while
> Rebecca (rolfe) was at the meeting where we discussed this, but it's a good
idea
> to loop her into this. I've CC'd her on this CL.
> > the user is typing makes sense.  What if I have 100 logins for a website
> > (because I am testing the website), and am trying to narrow down the list of
> > suggestions?
>
> I feel pretty strongly that we should be optimizing for the more common case
of
> two or three accounts, but this is a great question to loop a designer in on.

I agree that we should optimize for the more common case, but I'd like to keep
the less common case from becoming completely painful if possible.

> > I also don't recall whether we ever offer inline autocomplete for sites
where
> > the user has just a single username.  If so, I bet that's the most common
use
> > case, so I'd hate to see us get worse in our handling of that case.
> We do offer inline autocomplete for sites with a single username. But in those
> cases, we're also autofilling on load, so I'm no sure there's a huge advantage
> to inline autocomplete. That having been said, a middle ground that might make
> sense is inline autocompleting the field itself, but to leave the full list
> available. I don't love that approach, but I could be convinced.
> 
> The main issue that I care about is that the user can easily see the entire
list
> of credentials available. This, it turns out, is one of the main reasons web
> sites use autocomplete='off', is that they expect multiple accounts to be used
> on their site, and they don't want password managers confusing their users, so
> we want to make this frictionless as possible.

So, let's say that I have two usernames saved for a site: [email protected]
and [email protected].  I've typed "isher" into the field.  What's the
point of continuing to show "[email protected]" in the popup?  IMO the
user intent is pretty clearly not to log in with [email protected].

I think there's a notable difference in intent between interacting with the
field by typing, and interacting with the field by clicking (or, equivalently,
focusing in any other way, but not editing).  If I start typing, I'm going to be
surprised if the suggestions don't match what I've typed.  If I focus but don't
edit, then it's more likely that I want to see a complete set of suggestions.

Is that reasoning at all convincing? :)

[jww, 2014-02-18 21:50:42]

On 2014/02/14 23:27:00, Ilya Sherman wrote:
> On 2014/02/14 21:57:48, jww wrote:
> > On 2014/02/14 21:35:09, Ilya Sherman wrote:
> > > On 2014/02/14 21:30:48, jww wrote:
> > > > On 2014/02/14 21:12:49, Ilya Sherman wrote:
> > > > > Why are we removing inline autocomplete?  IMO that's complementary to
> > > showing
> > > > a
> > > > > popup, not competing with it.
> > > > 
> > > > The thinking is that it's more important to always show the full set of
> > > > credentials on a given site than to show any subset, otherwise users may
> get
> > > > confused about what credentials are available. Additionally, a flow
where
> a
> > > > click on the username element reveals the full list would have very odd
> > > > interactions with inline autocomplete. For example, if Chrome autofills
> the
> > > > username and password on load, and then the user clicks on the username,
> > > should
> > > > it show a full list of credentials? It was decided that, yes, that's
very
> > > > important, so the user can quickly see all accounts available to them.
But
> > > what
> > > > happens if they erase a character? Should Chrome all of a sudden start
> > inline
> > > > autocompleting? We thought that the best answer is that we should just
> show
> > > all
> > > > credentials at all time during autocomplete.
> > > 
> > > Hmm, was this logic run past a UX designer?  I think filtering the list
> while
> > Rebecca (rolfe) was at the meeting where we discussed this, but it's a good
> idea
> > to loop her into this. I've CC'd her on this CL.
> > > the user is typing makes sense.  What if I have 100 logins for a website
> > > (because I am testing the website), and am trying to narrow down the list
of
> > > suggestions?
> >
> > I feel pretty strongly that we should be optimizing for the more common case
> of
> > two or three accounts, but this is a great question to loop a designer in
on.
> 
> I agree that we should optimize for the more common case, but I'd like to keep
> the less common case from becoming completely painful if possible.
> 
> > > I also don't recall whether we ever offer inline autocomplete for sites
> where
> > > the user has just a single username.  If so, I bet that's the most common
> use
> > > case, so I'd hate to see us get worse in our handling of that case.
> > We do offer inline autocomplete for sites with a single username. But in
those
> > cases, we're also autofilling on load, so I'm no sure there's a huge
advantage
> > to inline autocomplete. That having been said, a middle ground that might
make
> > sense is inline autocompleting the field itself, but to leave the full list
> > available. I don't love that approach, but I could be convinced.
> > 
> > The main issue that I care about is that the user can easily see the entire
> list
> > of credentials available. This, it turns out, is one of the main reasons web
> > sites use autocomplete='off', is that they expect multiple accounts to be
used
> > on their site, and they don't want password managers confusing their users,
so
> > we want to make this frictionless as possible.
> 
> So, let's say that I have two usernames saved for a site:
mailto:[email protected]
> and mailto:[email protected].  I've typed "isher" into the field. 
What's the
> point of continuing to show "[email protected]" in the popup?  IMO the
> user intent is pretty clearly not to log in with
mailto:[email protected].
> 
> I think there's a notable difference in intent between interacting with the
> field by typing, and interacting with the field by clicking (or, equivalently,
> focusing in any other way, but not editing).  If I start typing, I'm going to
be
> surprised if the suggestions don't match what I've typed.  If I focus but
don't
> edit, then it's more likely that I want to see a complete set of suggestions.
> 
> Is that reasoning at all convincing? :)

Well, I'm not personally totally convinced, but the rolfe is (as described in
https://crbug.com/341474#c8). I'll upload a new CL with the hybrid system.

[gcasto (DO NOT USE), 2014-02-18 22:54:47]

Looks like I missed most of the discussion on this, but it ended up in a
place that I'm okay with. I think that consistency is important, but I
think that the signal we are getting from the user that they are not
interested in a suggestion should not be ignored. Previously I've argued
for having an additional UI element to allow us to show that multiple
passwords exists (and to easily switch between them) which would allow us
to keep the current dropdown consistent. That has it's own complications
though. Given that I prefer the hybrid system to the alternatives.


On Tue, Feb 18, 2014 at 1:50 PM, <[email protected]> wrote:

> On 2014/02/14 23:27:00, Ilya Sherman wrote:
>
>> On 2014/02/14 21:57:48, jww wrote:
>> > On 2014/02/14 21:35:09, Ilya Sherman wrote:
>> > > On 2014/02/14 21:30:48, jww wrote:
>> > > > On 2014/02/14 21:12:49, Ilya Sherman wrote:
>> > > > > Why are we removing inline autocomplete?  IMO that's
>> complementary to
>> > > showing
>> > > > a
>> > > > > popup, not competing with it.
>> > > >
>> > > > The thinking is that it's more important to always show the full
>> set of
>> > > > credentials on a given site than to show any subset, otherwise
>> users may
>> get
>> > > > confused about what credentials are available. Additionally, a flow
>>
> where
>
>> a
>> > > > click on the username element reveals the full list would have very
>> odd
>> > > > interactions with inline autocomplete. For example, if Chrome
>> autofills
>> the
>> > > > username and password on load, and then the user clicks on the
>> username,
>> > > should
>> > > > it show a full list of credentials? It was decided that, yes, that's
>>
> very
>
>> > > > important, so the user can quickly see all accounts available to
>> them.
>>
> But
>
>> > > what
>> > > > happens if they erase a character? Should Chrome all of a sudden
>> start
>> > inline
>> > > > autocompleting? We thought that the best answer is that we should
>> just
>> show
>> > > all
>> > > > credentials at all time during autocomplete.
>> > >
>> > > Hmm, was this logic run past a UX designer?  I think filtering the
>> list
>> while
>> > Rebecca (rolfe) was at the meeting where we discussed this, but it's a
>> good
>> idea
>> > to loop her into this. I've CC'd her on this CL.
>> > > the user is typing makes sense.  What if I have 100 logins for a
>> website
>> > > (because I am testing the website), and am trying to narrow down the
>> list
>>
> of
>
>> > > suggestions?
>> >
>> > I feel pretty strongly that we should be optimizing for the more common
>> case
>> of
>> > two or three accounts, but this is a great question to loop a designer
>> in
>>
> on.
>
>  I agree that we should optimize for the more common case, but I'd like to
>> keep
>> the less common case from becoming completely painful if possible.
>>
>
>  > > I also don't recall whether we ever offer inline autocomplete for
>> sites
>> where
>> > > the user has just a single username.  If so, I bet that's the most
>> common
>> use
>> > > case, so I'd hate to see us get worse in our handling of that case.
>> > We do offer inline autocomplete for sites with a single username. But in
>>
> those
>
>> > cases, we're also autofilling on load, so I'm no sure there's a huge
>>
> advantage
>
>> > to inline autocomplete. That having been said, a middle ground that
>> might
>>
> make
>
>> > sense is inline autocompleting the field itself, but to leave the full
>> list
>> > available. I don't love that approach, but I could be convinced.
>> >
>> > The main issue that I care about is that the user can easily see the
>> entire
>> list
>> > of credentials available. This, it turns out, is one of the main
>> reasons web
>> > sites use autocomplete='off', is that they expect multiple accounts to
>> be
>>
> used
>
>> > on their site, and they don't want password managers confusing their
>> users,
>>
> so
>
>> > we want to make this frictionless as possible.
>>
>
>  So, let's say that I have two usernames saved for a site:
>>
> mailto:[email protected]
>
>> and mailto:[email protected].  I've typed "isher" into the field.
>>
> What's the
>
>> point of continuing to show "[email protected]" in the popup?
>>  IMO the
>> user intent is pretty clearly not to log in with
>>
> mailto:[email protected].
>
>
>  I think there's a notable difference in intent between interacting with
>> the
>> field by typing, and interacting with the field by clicking (or,
>> equivalently,
>> focusing in any other way, but not editing).  If I start typing, I'm
>> going to
>>
> be
>
>> surprised if the suggestions don't match what I've typed.  If I focus but
>>
> don't
>
>> edit, then it's more likely that I want to see a complete set of
>> suggestions.
>>
>
>  Is that reasoning at all convincing? :)
>>
>
> Well, I'm not personally totally convinced, but the rolfe is (as described
> in
> https://crbug.com/341474#c8). I'll upload a new CL with the hybrid system.
>
> https://codereview.chromium.org/166043006/
>

To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].

[jww, 2014-02-18 23:48:20]

On 2014/02/18 22:54:47, gcasto wrote:
> Looks like I missed most of the discussion on this, but it ended up in a
> place that I'm okay with. I think that consistency is important, but I
> think that the signal we are getting from the user that they are not
> interested in a suggestion should not be ignored. Previously I've argued
> for having an additional UI element to allow us to show that multiple
> passwords exists (and to easily switch between them) which would allow us
> to keep the current dropdown consistent. That has it's own complications
> though. Given that I prefer the hybrid system to the alternatives.
> 
> 
> On Tue, Feb 18, 2014 at 1:50 PM, <mailto:[email protected]> wrote:
> 
> > On 2014/02/14 23:27:00, Ilya Sherman wrote:
> >
> >> On 2014/02/14 21:57:48, jww wrote:
> >> > On 2014/02/14 21:35:09, Ilya Sherman wrote:
> >> > > On 2014/02/14 21:30:48, jww wrote:
> >> > > > On 2014/02/14 21:12:49, Ilya Sherman wrote:
> >> > > > > Why are we removing inline autocomplete?  IMO that's
> >> complementary to
> >> > > showing
> >> > > > a
> >> > > > > popup, not competing with it.
> >> > > >
> >> > > > The thinking is that it's more important to always show the full
> >> set of
> >> > > > credentials on a given site than to show any subset, otherwise
> >> users may
> >> get
> >> > > > confused about what credentials are available. Additionally, a flow
> >>
> > where
> >
> >> a
> >> > > > click on the username element reveals the full list would have very
> >> odd
> >> > > > interactions with inline autocomplete. For example, if Chrome
> >> autofills
> >> the
> >> > > > username and password on load, and then the user clicks on the
> >> username,
> >> > > should
> >> > > > it show a full list of credentials? It was decided that, yes, that's
> >>
> > very
> >
> >> > > > important, so the user can quickly see all accounts available to
> >> them.
> >>
> > But
> >
> >> > > what
> >> > > > happens if they erase a character? Should Chrome all of a sudden
> >> start
> >> > inline
> >> > > > autocompleting? We thought that the best answer is that we should
> >> just
> >> show
> >> > > all
> >> > > > credentials at all time during autocomplete.
> >> > >
> >> > > Hmm, was this logic run past a UX designer?  I think filtering the
> >> list
> >> while
> >> > Rebecca (rolfe) was at the meeting where we discussed this, but it's a
> >> good
> >> idea
> >> > to loop her into this. I've CC'd her on this CL.
> >> > > the user is typing makes sense.  What if I have 100 logins for a
> >> website
> >> > > (because I am testing the website), and am trying to narrow down the
> >> list
> >>
> > of
> >
> >> > > suggestions?
> >> >
> >> > I feel pretty strongly that we should be optimizing for the more common
> >> case
> >> of
> >> > two or three accounts, but this is a great question to loop a designer
> >> in
> >>
> > on.
> >
> >  I agree that we should optimize for the more common case, but I'd like to
> >> keep
> >> the less common case from becoming completely painful if possible.
> >>
> >
> >  > > I also don't recall whether we ever offer inline autocomplete for
> >> sites
> >> where
> >> > > the user has just a single username.  If so, I bet that's the most
> >> common
> >> use
> >> > > case, so I'd hate to see us get worse in our handling of that case.
> >> > We do offer inline autocomplete for sites with a single username. But in
> >>
> > those
> >
> >> > cases, we're also autofilling on load, so I'm no sure there's a huge
> >>
> > advantage
> >
> >> > to inline autocomplete. That having been said, a middle ground that
> >> might
> >>
> > make
> >
> >> > sense is inline autocompleting the field itself, but to leave the full
> >> list
> >> > available. I don't love that approach, but I could be convinced.
> >> >
> >> > The main issue that I care about is that the user can easily see the
> >> entire
> >> list
> >> > of credentials available. This, it turns out, is one of the main
> >> reasons web
> >> > sites use autocomplete='off', is that they expect multiple accounts to
> >> be
> >>
> > used
> >
> >> > on their site, and they don't want password managers confusing their
> >> users,
> >>
> > so
> >
> >> > we want to make this frictionless as possible.
> >>
> >
> >  So, let's say that I have two usernames saved for a site:
> >>
> > mailto:[email protected]
> >
> >> and mailto:[email protected].  I've typed "isher" into the field.
> >>
> > What's the
> >
> >> point of continuing to show "[email protected]" in the popup?
> >>  IMO the
> >> user intent is pretty clearly not to log in with
> >>
> > mailto:[email protected].
> >
> >
> >  I think there's a notable difference in intent between interacting with
> >> the
> >> field by typing, and interacting with the field by clicking (or,
> >> equivalently,
> >> focusing in any other way, but not editing).  If I start typing, I'm
> >> going to
> >>
> > be
> >
> >> surprised if the suggestions don't match what I've typed.  If I focus but
> >>
> > don't
> >
> >> edit, then it's more likely that I want to see a complete set of
> >> suggestions.
> >>
> >
> >  Is that reasoning at all convincing? :)
> >>
> >
> > Well, I'm not personally totally convinced, but the rolfe is (as described
> > in
> > https://crbug.com/341474#c8). I'll upload a new CL with the hybrid system.
> >
> > https://codereview.chromium.org/166043006/
> >
> 
> To unsubscribe from this group and stop receiving emails from it, send an
email
> to mailto:[email protected].

Thanks, gcasto. For the record, I, too, would love a more general UI element to
switch between accounts. I think, though, that for now, this is a good
compromise.

[jww, 2014-02-19 02:21:54]

I've re-added inline autocomplete, so let me know how it looks now.

[Garrett Casto, 2014-02-19 21:20:18]

Another thing I was thinking of, if we make it so that we get the popup
immediately after clicking it seems like we should do the same after focus. That
is, it seems strange that focusing by clicking will give a different result than
focusing via tabbing.

https://codereview.chromium.org/166043006/diff/140001/components/autofill/con...
File components/autofill/content/renderer/autofill_agent.cc (right):

https://codereview.chromium.org/166043006/diff/140001/components/autofill/con...
components/autofill/content/renderer/autofill_agent.cc:292:
ShowSuggestions(element, true, false, true, false, true);
Ilya, are you okay with Autofill also showing on first click? I don't remember
this coming up explicitly.

I'm also not sure if this does exactly what we want. It seems like we want to
show all suggestions in the case where the user wants to change an autofilled
username, not if they click on the field again to move the cursor or re-select
the field after typing in their preferred username. I think that we want this to
be more like "show_all_if_autofilled". Does that sound right?

[jww, 2014-02-19 21:56:48]

https://codereview.chromium.org/166043006/diff/140001/components/autofill/con...
File components/autofill/content/renderer/autofill_agent.cc (right):

https://codereview.chromium.org/166043006/diff/140001/components/autofill/con...
components/autofill/content/renderer/autofill_agent.cc:292:
ShowSuggestions(element, true, false, true, false, true);
On 2014/02/19 21:20:19, Garrett Casto wrote:
> Ilya, are you okay with Autofill also showing on first click? I don't remember
> this coming up explicitly.
> 
> I'm also not sure if this does exactly what we want. It seems like we want to
> show all suggestions in the case where the user wants to change an autofilled
> username, not if they click on the field again to move the cursor or re-select
> the field after typing in their preferred username. I think that we want this
to
> be more like "show_all_if_autofilled". Does that sound right?

I'm worried that would be hard-to-understand behavior. My thought is that a
click means full list, no more no less. I'd hate for users to have to understand
a more complex UI experience.

I'm cool with the tabbing idea as well. Any other thoughts about that?

[jww, 2014-02-19 22:14:38]

https://codereview.chromium.org/166043006/diff/140001/components/autofill/con...
File components/autofill/content/renderer/autofill_agent.cc (right):

https://codereview.chromium.org/166043006/diff/140001/components/autofill/con...
components/autofill/content/renderer/autofill_agent.cc:292:
ShowSuggestions(element, true, false, true, false, true);
On 2014/02/19 21:56:48, jww wrote:
> On 2014/02/19 21:20:19, Garrett Casto wrote:
> > Ilya, are you okay with Autofill also showing on first click? I don't
remember
> > this coming up explicitly.
> > 
> > I'm also not sure if this does exactly what we want. It seems like we want
to
> > show all suggestions in the case where the user wants to change an
autofilled
> > username, not if they click on the field again to move the cursor or
re-select
> > the field after typing in their preferred username. I think that we want
this
> to
> > be more like "show_all_if_autofilled". Does that sound right?
> 
> I'm worried that would be hard-to-understand behavior. My thought is that a
> click means full list, no more no less. I'd hate for users to have to
understand
> a more complex UI experience.
> 
> I'm cool with the tabbing idea as well. Any other thoughts about that?

Obviously we're still waiting for comments on the tabbing idea, but looking into
it briefly, it appears it would be harder to get that right than I originally
thought. How would you feel about tabbing-to-get-menu as a separate CL?

Right now, you can still get the effect by erasing the username and getting the
full list, which is obviously not as convenient as just tabbing, but at least
it's possible.

[Ilya Sherman, 2014-02-19 23:47:37]

My thoughts:

(1) It would be nice to treat all methods of focusing the field, including
tabbing, as equals.  This is important for accessibility.  That said, since
there are workarounds, it's not critical to get this working immediately -- just
a very nice to have IMO.

(2) For non-password Autofill, we show the Autofill menu in response to a click
anywhere in the field, whether the cursor ends up at the end of the input or in
the middle.  It probably makes sense to be consistent with that (and ought to be
simpler, too, which is nice :]).

(3) For non-password Autofill, we only show the Autofill menu after the second
click.  This is because we're assuming that for a random web form, users are not
necessarily wanting to enter in their saved Autofill data, which might or might
not be relevant in context.  For passwords, IMO users are much more likely to be
interested in Chrome's assistive abilities than they are for non-password
Autofill.  Hence, I'd actually vote against technical consistency here, and show
the popup on the first click.  However, I think I recall Aurimas expressing some
concerns about taking this approach on Android, where screen real-estate is
quite limited.  Presumably that concern generalizes to all small screens.  I'm
not sure that I understand why the menu is more in the way on Android than on
desktop, though -- for a login form, there are usually only two fields, and the
menu either is or is not tall enough to cover up the password field.  So, in
short, I'd vote for showing the password autofill menu as soon as the field is
focused.

(Please let me know if you'd like me to look at the details of the code as well.
 Otherwise, I'm just going to pay attention to the high-level behavioral
discussion.)

[Garrett Casto, 2014-02-20 00:20:01]

On Wed, Feb 19, 2014 at 3:47 PM, <[email protected]> wrote:

> My thoughts:
>
> (1) It would be nice to treat all methods of focusing the field, including
> tabbing, as equals.  This is important for accessibility.  That said, since
> there are workarounds, it's not critical to get this working immediately
> -- just
> a very nice to have IMO.
>
>
Doing this in a latter CL sounds fine to me as well. Just wanted to bring
it up.


> (2) For non-password Autofill, we show the Autofill menu in response to a
> click
> anywhere in the field, whether the cursor ends up at the end of the input
> or in
> the middle.  It probably makes sense to be consistent with that (and ought
> to be
> simpler, too, which is nice :]).
>

I wasn't trying to argue about the location of the click, more the context.
My argument is basically if the password field is autofilled and the user
selects the username field, then showing all usernames is reasonable since
it's likely that they are trying to change what was autofilled. However if
they are typing in the field and click inside it again, or deselect the
field and reselect it, it doesn't seem like showing all the usernames is
the optimal thing to do. As Joel mentioned, you do lose out on consistency
if you treat autofilled vs. non-autofilled differently so it's not
completely obvious which is the right answer. I think that the first case
seems very icky to me and I would really like to avoid it (e.g. clicking in
the middle of inline autocompleting causing the popup to change). The
second case is annoying, but I could be convinced to deal with it as it
seems less likely to happen and less clear what the user actually expects.


> (3) For non-password Autofill, we only show the Autofill menu after the
> second
> click.  This is because we're assuming that for a random web form, users
> are not
> necessarily wanting to enter in their saved Autofill data, which might or
> might
> not be relevant in context.  For passwords, IMO users are much more likely
> to be
> interested in Chrome's assistive abilities than they are for non-password
> Autofill.  Hence, I'd actually vote against technical consistency here,
> and show
> the popup on the first click.  However, I think I recall Aurimas
> expressing some
> concerns about taking this approach on Android, where screen real-estate is
> quite limited.  Presumably that concern generalizes to all small screens.
>  I'm
> not sure that I understand why the menu is more in the way on Android than
> on
> desktop, though -- for a login form, there are usually only two fields,
> and the
> menu either is or is not tall enough to cover up the password field.  So,
> in
> short, I'd vote for showing the password autofill menu as soon as the
> field is
> focused.
>
>
I might not have been clear enough but my concern was kind of the opposite.
That is, the current code changes this would make it so that non-password
Autofill would also show up after one click. It sounds like that's not on
the table, which is what I wanted to make sure of.


> (Please let me know if you'd like me to look at the details of the code as
> well.
>  Otherwise, I'm just going to pay attention to the high-level behavioral
> discussion.)
>
> https://codereview.chromium.org/166043006/
>

To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].

[Ilya Sherman, 2014-02-20 00:27:58]

On 2014/02/20 00:20:01, Garrett Casto wrote:
> On Wed, Feb 19, 2014 at 3:47 PM, <mailto:[email protected]> wrote:
> > (2) For non-password Autofill, we show the Autofill menu in response to a
> > click
> > anywhere in the field, whether the cursor ends up at the end of the input
> > or in
> > the middle.  It probably makes sense to be consistent with that (and ought
> > to be
> > simpler, too, which is nice :]).
> >
> 
> I wasn't trying to argue about the location of the click, more the context.
> My argument is basically if the password field is autofilled and the user
> selects the username field, then showing all usernames is reasonable since
> it's likely that they are trying to change what was autofilled. However if
> they are typing in the field and click inside it again, or deselect the
> field and reselect it, it doesn't seem like showing all the usernames is
> the optimal thing to do. As Joel mentioned, you do lose out on consistency
> if you treat autofilled vs. non-autofilled differently so it's not
> completely obvious which is the right answer. I think that the first case
> seems very icky to me and I would really like to avoid it (e.g. clicking in
> the middle of inline autocompleting causing the popup to change). The
> second case is annoying, but I could be convinced to deal with it as it
> seems less likely to happen and less clear what the user actually expects.

Ah, I see.  Yeah, I think only showing the full list of usernames when the user
is not in the middle of editing the field makes sense.

[jww, 2014-02-21 02:43:27]

I misunderstood Garrett's point about first-click suggestions on general
Autofill. I've fixed that. Also, I've updated it so it only shows the list on
first click if the field is already autocompleted.

https://codereview.chromium.org/166043006/diff/140001/components/autofill/con...
File components/autofill/content/renderer/autofill_agent.cc (right):

https://codereview.chromium.org/166043006/diff/140001/components/autofill/con...
components/autofill/content/renderer/autofill_agent.cc:292:
ShowSuggestions(element, true, false, true, false, true);
On 2014/02/19 22:14:39, jww wrote:
> On 2014/02/19 21:56:48, jww wrote:
> > On 2014/02/19 21:20:19, Garrett Casto wrote:
> > > Ilya, are you okay with Autofill also showing on first click? I don't
> remember
> > > this coming up explicitly.
> > > 
> > > I'm also not sure if this does exactly what we want. It seems like we want
> to
> > > show all suggestions in the case where the user wants to change an
> autofilled
> > > username, not if they click on the field again to move the cursor or
> re-select
> > > the field after typing in their preferred username. I think that we want
> this
> > to
> > > be more like "show_all_if_autofilled". Does that sound right?
> > 
> > I'm worried that would be hard-to-understand behavior. My thought is that a
> > click means full list, no more no less. I'd hate for users to have to
> understand
> > a more complex UI experience.
> > 
> > I'm cool with the tabbing idea as well. Any other thoughts about that?
> 
> Obviously we're still waiting for comments on the tabbing idea, but looking
into
> it briefly, it appears it would be harder to get that right than I originally
> thought. How would you feel about tabbing-to-get-menu as a separate CL?
> 
> Right now, you can still get the effect by erasing the username and getting
the
> full list, which is obviously not as convenient as just tabbing, but at least
> it's possible.

My bad. I misunderstood your point in a similar way to Ilya. I've fixed this
now, I think.

[Garrett Casto, 2014-02-24 23:45:09]

We should really add a test for the new show all behavior. I can think of two
ways of doing this. The first is to change TestPasswordAutofillAgent to be
similar to TestPasswordGenerationAgent where it catches outbound IPC's and would
just check to the suggestions in the IPC. The other alternative would be to
actually have this test in the browser and actually have the popup appear and
verify that you can select multiple different usernames that don't have a
matching prefix.

The first idea seems better because it's likely to be less code and it preserve
the current testing division which is PasswordManagerBrowsertest deals with
saving and PasswordAutofillAgentBrowsertest deals with filling. So I would go
with that unless there is some issue that I haven't thought of yet.

https://codereview.chromium.org/166043006/diff/250001/chrome/renderer/autofil...
File chrome/renderer/autofill/password_autofill_agent_browsertest.cc (right):

https://codereview.chromium.org/166043006/diff/250001/chrome/renderer/autofil...
chrome/renderer/autofill/password_autofill_agent_browsertest.cc:851: // the
autofill choice from the dropdown, thus causing an autofill.
Just calling textFieldDidEndEditing() (or possibly focusing a different field?)
is an easier way to get the username to really fill and is closer to what the
test was originally trying to do.

https://codereview.chromium.org/166043006/diff/250001/chrome/renderer/autofil...
chrome/renderer/autofill/password_autofill_agent_browsertest.cc:1050: // a
suggestion from the autofill suggestion list. {
1) I think that this test is trying to verify that one click is sufficient to
get the popup, but that's not obvious from the comment.
2) Trailing "{"

https://codereview.chromium.org/166043006/diff/250001/chrome/renderer/autofil...
chrome/renderer/autofill/password_autofill_agent_browsertest.cc:1058:
SimulateElementClick(kUsernameName);
Is this necessary to focus the element? As it's currently setup it looks like
you are simulating two clicks on the element (here and the additional
InputElementClicked() in SimulateSuggestionChoice()). If they are serving
different purposes, you probably want to document why they are called.

https://codereview.chromium.org/166043006/diff/250001/components/autofill/con...
File components/autofill/content/renderer/autofill_agent.h (right):

https://codereview.chromium.org/166043006/diff/250001/components/autofill/con...
components/autofill/content/renderer/autofill_agent.h:154: bool
show_password_suggestions_only);
This scares me a little, as it seems pretty easy to switch some of these around
on accident. But it was like this before, so I guess as long as we unit test
well enough it should be okay.

[jww, 2014-03-05 02:11:39]

On 2014/02/24 23:45:09, Garrett Casto wrote:
> We should really add a test for the new show all behavior. I can think of two
> ways of doing this. The first is to change TestPasswordAutofillAgent to be
> similar to TestPasswordGenerationAgent where it catches outbound IPC's and
would
> just check to the suggestions in the IPC. The other alternative would be to
> actually have this test in the browser and actually have the popup appear and
> verify that you can select multiple different usernames that don't have a
> matching prefix.
> 
> The first idea seems better because it's likely to be less code and it
preserve
> the current testing division which is PasswordManagerBrowsertest deals with
> saving and PasswordAutofillAgentBrowsertest deals with filling. So I would go
> with that unless there is some issue that I haven't thought of yet.
I took your suggestion and went with the first approach.
> 
>
https://codereview.chromium.org/166043006/diff/250001/chrome/renderer/autofil...
> File chrome/renderer/autofill/password_autofill_agent_browsertest.cc (right):
> 
>
https://codereview.chromium.org/166043006/diff/250001/chrome/renderer/autofil...
> chrome/renderer/autofill/password_autofill_agent_browsertest.cc:851: // the
> autofill choice from the dropdown, thus causing an autofill.
> Just calling textFieldDidEndEditing() (or possibly focusing a different
field?)
> is an easier way to get the username to really fill and is closer to what the
> test was originally trying to do.
> 
>
https://codereview.chromium.org/166043006/diff/250001/chrome/renderer/autofil...
> chrome/renderer/autofill/password_autofill_agent_browsertest.cc:1050: // a
> suggestion from the autofill suggestion list. {
> 1) I think that this test is trying to verify that one click is sufficient to
> get the popup, but that's not obvious from the comment.
> 2) Trailing "{"
> 
>
https://codereview.chromium.org/166043006/diff/250001/chrome/renderer/autofil...
> chrome/renderer/autofill/password_autofill_agent_browsertest.cc:1058:
> SimulateElementClick(kUsernameName);
> Is this necessary to focus the element? As it's currently setup it looks like
> you are simulating two clicks on the element (here and the additional
> InputElementClicked() in SimulateSuggestionChoice()). If they are serving
> different purposes, you probably want to document why they are called.
> 
>
https://codereview.chromium.org/166043006/diff/250001/components/autofill/con...
> File components/autofill/content/renderer/autofill_agent.h (right):
> 
>
https://codereview.chromium.org/166043006/diff/250001/components/autofill/con...
> components/autofill/content/renderer/autofill_agent.h:154: bool
> show_password_suggestions_only);
> This scares me a little, as it seems pretty easy to switch some of these
around
> on accident. But it was like this before, so I guess as long as we unit test
> well enough it should be okay.

[jww, 2014-03-05 02:11:48]

https://codereview.chromium.org/166043006/diff/250001/chrome/renderer/autofil...
File chrome/renderer/autofill/password_autofill_agent_browsertest.cc (right):

https://codereview.chromium.org/166043006/diff/250001/chrome/renderer/autofil...
chrome/renderer/autofill/password_autofill_agent_browsertest.cc:851: // the
autofill choice from the dropdown, thus causing an autofill.
On 2014/02/24 23:45:09, Garrett Casto wrote:
> Just calling textFieldDidEndEditing() (or possibly focusing a different
field?)
> is an easier way to get the username to really fill and is closer to what the
> test was originally trying to do.

Calling textFieldDidEndEditing() is insufficient because of the need to wait for
the event loop and what-not, but you're right that this test can be simpler, so
I've pretty much reverted it back to its original state. (The extra complexity
was actually because I originally eliminated inline autocomplete, which is now
back.)

https://codereview.chromium.org/166043006/diff/250001/chrome/renderer/autofil...
chrome/renderer/autofill/password_autofill_agent_browsertest.cc:1050: // a
suggestion from the autofill suggestion list. {
On 2014/02/24 23:45:09, Garrett Casto wrote:
> 1) I think that this test is trying to verify that one click is sufficient to
> get the popup, but that's not obvious from the comment.
> 2) Trailing "{"

I've update the comment to be more specific, but do let me know if it's still
confusing.

https://codereview.chromium.org/166043006/diff/250001/chrome/renderer/autofil...
chrome/renderer/autofill/password_autofill_agent_browsertest.cc:1058:
SimulateElementClick(kUsernameName);
On 2014/02/24 23:45:09, Garrett Casto wrote:
> Is this necessary to focus the element? As it's currently setup it looks like
> you are simulating two clicks on the element (here and the additional
> InputElementClicked() in SimulateSuggestionChoice()). If they are serving
> different purposes, you probably want to document why they are called.
Yeah, it's a bit odd because the SimulateElementClick doesn't actually call into
the AutofillAgent, so we have to manually call InputElementClicked. I'll make a
note of it.

https://codereview.chromium.org/166043006/diff/250001/components/autofill/con...
File components/autofill/content/renderer/autofill_agent.h (right):

https://codereview.chromium.org/166043006/diff/250001/components/autofill/con...
components/autofill/content/renderer/autofill_agent.h:154: bool
show_password_suggestions_only);
On 2014/02/24 23:45:09, Garrett Casto wrote:
> This scares me a little, as it seems pretty easy to switch some of these
around
> on accident. But it was like this before, so I guess as long as we unit test
> well enough it should be okay.

I agree, although I'm not sure I see a better alternative.

[Garrett Casto, 2014-03-06 01:23:45]

https://codereview.chromium.org/166043006/diff/350001/chrome/renderer/autofil...
File chrome/renderer/autofill/password_autofill_agent_browsertest.cc (right):

https://codereview.chromium.org/166043006/diff/350001/chrome/renderer/autofil...
chrome/renderer/autofill/password_autofill_agent_browsertest.cc:1112:
password_autofill_->pause_messages();
I'd probably remove pause_messages() and resume_message() and just check the
last sent message. For renderer browser tests, there is no one listening on the
other side of the IPC anyway, so it doesn't actually matter if they are sent or
not. I'm not sure if it's worth adding them to the API of
TestPasswordAutofillAgent just to verify that only one IPC was sent (since
really we don't care that only one was send).

https://codereview.chromium.org/166043006/diff/350001/chrome/renderer/autofil...
chrome/renderer/autofill/password_autofill_agent_browsertest.cc:1120: // with
all the usernames.
I think that we have a misunderstanding somewhere, because this is the opposite
of what I was arguing for earlier :). I think that you shouldn't show all
usernames if you click while in the middle of typing. Stomping on inline
autocomplete seems like a bad user experience.

https://codereview.chromium.org/166043006/diff/350001/chrome/renderer/autofil...
chrome/renderer/autofill/password_autofill_agent_browsertest.cc:1122:
password_autofill_->pause_messages();
I'd probably remove pause_messages() and resume_message() and just check the
last sent message. For renderer browser tests, there is no one listening on the
other side of the IPC anyway, so it doesn't actually matter if they are sent or
not. I'm not sure if it's worth adding them to the API of
TestPasswordAutofillAgent just to verify that only one IPC was sent, since we
don't care about the total number of IPCs anyway.

https://codereview.chromium.org/166043006/diff/350001/components/autofill/con...
File components/autofill/content/renderer/autofill_agent.cc (right):

https://codereview.chromium.org/166043006/diff/350001/components/autofill/con...
components/autofill/content/renderer/autofill_agent.cc:295: bool
show_full_suggestion_list = element.isAutofilled() || was_focused;
I think that this was fine before hand with just element.isAutofilled().

[jww, 2014-03-07 02:06:05]

https://codereview.chromium.org/166043006/diff/350001/chrome/renderer/autofil...
File chrome/renderer/autofill/password_autofill_agent_browsertest.cc (right):

https://codereview.chromium.org/166043006/diff/350001/chrome/renderer/autofil...
chrome/renderer/autofill/password_autofill_agent_browsertest.cc:1112:
password_autofill_->pause_messages();
On 2014/03/06 01:23:46, Garrett Casto wrote:
> I'd probably remove pause_messages() and resume_message() and just check the
> last sent message. For renderer browser tests, there is no one listening on
the
> other side of the IPC anyway, so it doesn't actually matter if they are sent
or
> not. I'm not sure if it's worth adding them to the API of
> TestPasswordAutofillAgent just to verify that only one IPC was sent (since
> really we don't care that only one was send).

Yeah, I was overthinking it. I've modified the test to just use the
render_thread_->sink() message methods.

https://codereview.chromium.org/166043006/diff/350001/chrome/renderer/autofil...
chrome/renderer/autofill/password_autofill_agent_browsertest.cc:1120: // with
all the usernames.
On 2014/03/06 01:23:46, Garrett Casto wrote:
> I think that we have a misunderstanding somewhere, because this is the
opposite
> of what I was arguing for earlier :). I think that you shouldn't show all
> usernames if you click while in the middle of typing. Stomping on inline
> autocomplete seems like a bad user experience.

No misunderstanding; just a screw-up on my part.

https://codereview.chromium.org/166043006/diff/350001/chrome/renderer/autofil...
chrome/renderer/autofill/password_autofill_agent_browsertest.cc:1122:
password_autofill_->pause_messages();
On 2014/03/06 01:23:46, Garrett Casto wrote:
> I'd probably remove pause_messages() and resume_message() and just check the
> last sent message. For renderer browser tests, there is no one listening on
the
> other side of the IPC anyway, so it doesn't actually matter if they are sent
or
> not. I'm not sure if it's worth adding them to the API of
> TestPasswordAutofillAgent just to verify that only one IPC was sent, since we
> don't care about the total number of IPCs anyway.

Done.

https://codereview.chromium.org/166043006/diff/350001/components/autofill/con...
File components/autofill/content/renderer/autofill_agent.cc (right):

https://codereview.chromium.org/166043006/diff/350001/components/autofill/con...
components/autofill/content/renderer/autofill_agent.cc:295: bool
show_full_suggestion_list = element.isAutofilled() || was_focused;
On 2014/03/06 01:23:46, Garrett Casto wrote:
> I think that this was fine before hand with just element.isAutofilled().

I changed this because the experience, I felt, was very odd that if you typed in
"goo" instead of "foo" (for example), there was no way to get the full list of
credentials. This actually happened to me while I was testing :-P Let me know if
you disagree with that experience, though.

I've actually made this more complicated in the latest CL as well, to fix the
broken case of editing an autocompleted entry.

[Garrett Casto, 2014-03-12 06:50:44]

https://codereview.chromium.org/166043006/diff/370001/components/autofill/con...
File components/autofill/content/renderer/autofill_agent.cc (right):

https://codereview.chromium.org/166043006/diff/370001/components/autofill/con...
components/autofill/content/renderer/autofill_agent.cc:296:
(!element.isAutofilled() && was_focused);
This seems overly complicated to me. If the element is autofilled and you double
click on the field instead of single click, do you really want to dismiss all
the suggestions on the second click? For the same reason I don't see how the
!element.isAutofilled() is relevant on the next line. 

So I think that you just want element.isAutofilled() || was_focused. Perhaps you
are thinking about this differently, but it seems like there are two cases you
are trying to catch.

1) If the user clicks on an already autofilled entry, we immediately show all
suggestions since it's likely that they are trying to change the already
autofilled entry.
2) If the user is typing something and for some reason still wants to override
inline autocomplete (because the mistyped for instance) they can click on the
input field again.

I've been arguing against 2) so far because I thought that it was not a great
user experience to change the autofill dropdown in mid edit. I hadn't thought
specifically of the mistyping case, but I thought that people would just choose
the username that they wanted on click now if they didn't intend to use inline
autocomplete.

I'm skeptical that this is really better as a user experience, but I'm willing
to let it go. I do think that we should probably add some UMA stats for this to
see how often people make use of either of these cases in practice. Doesn't need
to be in this CL. Part of the reason that I'm okay with this is that I'm
guessing usage is low enough for the click during inline autocomplete that it
doesn't matter much.

[jww, 2014-03-19 01:08:01]

https://codereview.chromium.org/166043006/diff/370001/components/autofill/con...
File components/autofill/content/renderer/autofill_agent.cc (right):

https://codereview.chromium.org/166043006/diff/370001/components/autofill/con...
components/autofill/content/renderer/autofill_agent.cc:296:
(!element.isAutofilled() && was_focused);
On 2014/03/12 06:50:45, Garrett Casto wrote:
> This seems overly complicated to me. If the element is autofilled and you
double
> click on the field instead of single click, do you really want to dismiss all
> the suggestions on the second click? For the same reason I don't see how the
> !element.isAutofilled() is relevant on the next line.
This is for the case you argue for later, not creating a full list when you've
already got an inline autocomplete. That is, we only create a full list when
it's already autofilled it it was already focused.
> 
> So I think that you just want element.isAutofilled() || was_focused. Perhaps
you
> are thinking about this differently, but it seems like there are two cases you
> are trying to catch.
> 
> 1) If the user clicks on an already autofilled entry, we immediately show all
> suggestions since it's likely that they are trying to change the already
> autofilled entry.
> 2) If the user is typing something and for some reason still wants to override
> inline autocomplete (because the mistyped for instance) they can click on the
> input field again.
> 
> I've been arguing against 2) so far because I thought that it was not a great
> user experience to change the autofill dropdown in mid edit. I hadn't thought
> specifically of the mistyping case, but I thought that people would just
choose
> the username that they wanted on click now if they didn't intend to use inline
> autocomplete.
> 
> I'm skeptical that this is really better as a user experience, but I'm willing
> to let it go. I do think that we should probably add some UMA stats for this
to
> see how often people make use of either of these cases in practice. Doesn't
need
> to be in this CL. Part of the reason that I'm okay with this is that I'm
> guessing usage is low enough for the click during inline autocomplete that it
> doesn't matter much.
This analysis makes sense to me. I'll make the change, and I'll start a spearate
CL with UMA stats.

[Garrett Casto, 2014-03-19 20:54:39]

https://codereview.chromium.org/166043006/diff/370001/components/autofill/con...
File components/autofill/content/renderer/autofill_agent.cc (right):

https://codereview.chromium.org/166043006/diff/370001/components/autofill/con...
components/autofill/content/renderer/autofill_agent.cc:296:
(!element.isAutofilled() && was_focused);
On 2014/03/19 01:08:02, jww wrote:
> On 2014/03/12 06:50:45, Garrett Casto wrote:
> > This seems overly complicated to me. If the element is autofilled and you
> double
> > click on the field instead of single click, do you really want to dismiss
all
> > the suggestions on the second click? For the same reason I don't see how the
> > !element.isAutofilled() is relevant on the next line.
> This is for the case you argue for later, not creating a full list when you've
> already got an inline autocomplete. That is, we only create a full list when
> it's already autofilled it it was already focused.

Ahh, my fault. For some reason I thought that we weren't marking the field as
autofilled during inline autocomplete. This makes more sense now. I'm cool with
keeping it this way as well then, though I would add comments to clarify the two
cases so that other aren't confused as well.

[jww, 2014-06-20 18:43:46]

Sorry for letting this CL get long in the tooth; I just lost track of it.

This is mainly just a rebase on ToT, although I did make one change as mentioned
in the comments. Let me know what you think.

https://codereview.chromium.org/166043006/diff/370001/components/autofill/con...
File components/autofill/content/renderer/autofill_agent.cc (right):

https://codereview.chromium.org/166043006/diff/370001/components/autofill/con...
components/autofill/content/renderer/autofill_agent.cc:296:
(!element.isAutofilled() && was_focused);
On 2014/03/19 20:54:41, Garrett Casto wrote:
> On 2014/03/19 01:08:02, jww wrote:
> > On 2014/03/12 06:50:45, Garrett Casto wrote:
> > > This seems overly complicated to me. If the element is autofilled and you
> > double
> > > click on the field instead of single click, do you really want to dismiss
> all
> > > the suggestions on the second click? For the same reason I don't see how
the
> > > !element.isAutofilled() is relevant on the next line.
> > This is for the case you argue for later, not creating a full list when
you've
> > already got an inline autocomplete. That is, we only create a full list when
> > it's already autofilled it it was already focused.
> 
> Ahh, my fault. For some reason I thought that we weren't marking the field as
> autofilled during inline autocomplete. This makes more sense now. I'm cool
with
> keeping it this way as well then, though I would add comments to clarify the
two
> cases so that other aren't confused as well.

So I've actually had a bit of a change of heart on this behavior, as you'll see
in the latest patch. I was playing around with it a bunch, and it's just a weird
and inconsistent set of behaviors. For example, if we're inline autocompleting
and we prevent retrieval of the full list via another click, then it's very
unintuitive that the answer is to erase the entire username (when it only
required a click earlier).

Additionally, if I click somewhere in the field, that probably means I mistyped
something, so it's nice to get a full list immediately where I can select the
right answer (until I start typing again, at which point the reduced, inline
autocomplete selection jumps in).

Let me know if that reasoning makes sense to you.

[Garrett Casto, 2014-07-15 22:17:20]

I think that your reasoning seems fine. In particular, that a user clicking back
in the username field to edit getting the full dropdown again seems reasonable.
It might be slightly better if we only showed thisif the cursor moved back, but
that also might just be overly complicated. Let's see how people react to this
first.

LGTM modulo suggestions.

https://codereview.chromium.org/166043006/diff/410001/chrome/renderer/autofil...
File chrome/renderer/autofill/password_autofill_agent_browsertest.cc (right):

https://codereview.chromium.org/166043006/diff/410001/chrome/renderer/autofil...
chrome/renderer/autofill/password_autofill_agent_browsertest.cc:1437: //
Specifiaclly, tests when the user clicks on the username element after page
Specifically

https://codereview.chromium.org/166043006/diff/410001/components/autofill/con...
File components/autofill/content/renderer/autofill_agent.cc (right):

https://codereview.chromium.org/166043006/diff/410001/components/autofill/con...
components/autofill/content/renderer/autofill_agent.cc:380: if
(password_autofill_agent_->TextDidChangeInTextField(*input_element)) {
Was this change intentional? Seems like it would crash if input_element is NULL.

[jww, 2014-07-15 22:48:26]

https://codereview.chromium.org/166043006/diff/410001/chrome/renderer/autofil...
File chrome/renderer/autofill/password_autofill_agent_browsertest.cc (right):

https://codereview.chromium.org/166043006/diff/410001/chrome/renderer/autofil...
chrome/renderer/autofill/password_autofill_agent_browsertest.cc:1437: //
Specifiaclly, tests when the user clicks on the username element after page
On 2014/07/15 22:17:19, Garrett Casto wrote:
> Specifically

Done.

https://codereview.chromium.org/166043006/diff/410001/components/autofill/con...
File components/autofill/content/renderer/autofill_agent.cc (right):

https://codereview.chromium.org/166043006/diff/410001/components/autofill/con...
components/autofill/content/renderer/autofill_agent.cc:380: if
(password_autofill_agent_->TextDidChangeInTextField(*input_element)) {
On 2014/07/15 22:17:19, Garrett Casto wrote:
> Was this change intentional? Seems like it would crash if input_element is
NULL.

No, I think this was a rebase mistake. Good catch!

[jww, 2014-07-15 22:48:32]

The CQ bit was checked by [email protected]

[jww, 2014-07-15 22:48:44]

The CQ bit was unchecked by [email protected]

[jww, 2014-07-15 22:51:46]

The CQ bit was checked by [email protected]

[commit-bot: I haz the power, 2014-07-15 22:53:36]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/[email protected]/166043006/450001

[commit-bot: I haz the power, 2014-07-16 07:28:15]

Change committed as 283383