578572 - User autocomplete ignores letters typed while a response is pending

Status: RESOLVED FIXED

(Bugzilla :: User Interface, defect)

Description

[Dave Miller [:justdave]]

If you type several letters into a user field, it appears to start auto-matching on the first letter you type, and any letters you type after that before it gets a response back are ignored (for purposes of matching). So if you rapidly type in "justd" expecting that to match stuff with "justd" in it, and you finish typing those letters before the response comes back, you wind up with a huge autocomplete dropdown just with stuff starting with j. Typing the "a" after that re-filters it correctly, but when you're looking at "justd" in the textbox, you expect the results in the dropdown to actually match that.

Comment 1

[Dave Miller [:justdave]]

fwiw, I actually can't reproduce this on landfill... perhaps it's something specific to bmo's backport of this feature?

Comment 2

[Max Kanat-Alexander]

It might have to do with the order that requests are completing in, which could be more wildly variant on bmo than on landfill. There's a simple parameter adjustment that we can make to the YUI Autocomplete control to make it cancel pending requests if a new one is about to be sent.

Comment 3

[Max Kanat-Alexander]

Attachment: v1

Okay, in addition to fixing this bug, this also spiffs up the user autocomplete code a bit:

 * I synced the styles between the keywords autocomplete and the user autocomplete, so now they both do overflow.

* I made the user autocomplete use the maxusermatches parameter to determine how many users it's going to show (instead of having it just always show 10, which wasn't always enough in my actual usage of the field).

* I removed the "fields" item from the dataSource configuration because it's actually unnecessary.

* I made the connections time out if they take too long (longer than 30 seconds).

* I made the autocomplete cache the last five lookups the user did on this page, so that if you do something in the CC field like "mozilla, mozilla," the second match will come up immediately.

* And finally, to fix this bug, I set connXhrMode = "cancelStaleRequests", which should prevent the sort of races that large, load-balanced installations are going to inevitably be prone to with this feature if multiple requests are made while typing in the field.

Comment 4

[Guy Pyrzak]

Comment on attachment 459760 [details] [diff] [review]
v1

Not sure why you deleted the fields argument, but I don't think it will break anything. Otherwise, yes you did what you said you'd do. Not sure it'll fix the BMO issue, but I haven't run into it myself.

Comment 5

[Guy Pyrzak]

Comment on attachment 459760 [details] [diff] [review]
v1

Not sure why you deleted the fields argument, but I don't think it will break anything. Otherwise, yes you did what you said you'd do. Not sure it'll fix the BMO issue, but I haven't run into it myself.

Comment 6

[Max Kanat-Alexander]

(In reply to comment #5)
> Not sure why you deleted the fields argument,

  Just as a cleanup. :-)

> Not sure it'll fix the BMO issue, but I haven't run into it myself.

  Okay. I suspect it will--the default for that property is allowAll, which means that if requests arrive out of order, then the autocomplete may be populated via an old request.

Comment 7

[Max Kanat-Alexander]

Thanks for the review, pyrzak! :-)

Comment 8

[Max Kanat-Alexander]

Committing to: bzr+ssh://bzr.mozilla.org/bugzilla/trunk/                       
modified js/field.js
modified skins/standard/global.css
modified template/en/default/global/header.html.tmpl
Committed revision 7414.

Committing to: bzr+ssh://bzr.mozilla.org/bugzilla/4.0/                         
modified js/field.js
modified skins/standard/global.css
modified template/en/default/global/header.html.tmpl
Committed revision 7357.