Comment 10 for bug 800361

> >From a previous discussion we were talking about removing that field
> altogether and replacing it with just the result. Having an input field
> that gets populated from the picker does not give confidence that you've
> actually selected the correct person, especially if what is entered into
> that field is not what you might see in the picker (you might click on
> "Huw Wilkins" and the input is populated with "huwshimi").
>
>> Get rid of the 'choose' link and the popup window. Let people type in
>> the person field directly, and show a drop down menu of matching
>> names, with the exact match first, and decorated with affiliation,
>> email, and other information.
>
> I think we also talked about that being too costly performance-wise at
> this point.

Of course performance is a concern, but:

If you know you definitely want to assign it to ~mbp, you can just
type that and the autocomplete speed doesn't matter.

If you want 'martin pool' and you don't know the userid, you're going
to have to wait for at least one search in the current dialog, and
doing that search from a dropdown shouldn't need to be any slower.

The dropdown by not having a single explicit user action to initiate a
search might end up with more requests being started and aborted (or
not aborted, and running on pointlessly), and we'd want to make sure
early searches didn't block out later ones. But there is in theory
already client code and patterns to do this efficiently as Robert
says.

> We also return to the problem of people often requiring
> quite a bit of information to make a decision about who to select.

That's a question of whether the information that the LEP says must be
displayed can fit into a reasonably sized dropdown list item? I think
it can; showing too much text is not going to help...