Closed
Bug 392633
Opened 18 years ago
Closed 10 years ago
[Search suggestion of search plugin] Suggestion display is broken if fast user typing overruns slow server response
Categories
(Firefox :: Search, defect)
Tracking
()
RESOLVED
INCOMPLETE
People
(Reporter: syryos, Unassigned)
References
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6
Search bar with a suggesting search plugin:
No suggestions are not shown when the answering server is comparatively slow and the user type too fast. It appears, that the asynchronous communication may break under such conditions.
Let me explain mny observation and give a suggestion for solution, which works well in other programms:
The developers are ask to check the XHR modules and to make that specific client-server communication more robust. I suggest to use a lastsentrequest variable and _resubmit the XHR also from inside the _callback handler on the condition that the currentinputfield <> lastsentrequest. This is the condition that the user typing is overtaking the meanwhile outdated server response.
Simply fire a new request from inside the callback handler (if the input field has changed since the XHR).
Reproducible: Always
You can contact me for further information. I have no public URL available for you which demonstrates this bug publically.
/* sniplet */
var lastreq='';
var waitingreq='';
//Our XmlHttpRequest object to get the auto suggest
var searchReq = getXmlHttpRequestObject();
//Called from keyup on the search textbox. Starts the AJAX request.
function Suggest(event,what,querystring) {
if (event=='enter' || event.keyCode==13) {
fv=document.getElementById('txtSearch').value;
if (event=='enter') fn='q';
else fn=what.name;
}
var str=encodeURIComponent(document.getElementById('txtSearch').value);
curreq = SuggestURL+str;
// readyState Status Codes:
// 0 = uninitialized
// 4 = complete
if ( (searchReq.readyState==4 || searchReq.readyState==0) && curreq!='' && curreq!=lastreq ) {
if ((typeof querystring != 'undefined') && (querystring != '')) {
setSearch(str);
}
curreq = SuggestURL+str;
searchReq.open("GET", curreq, true);
searchReq.onreadystatechange=handleSuggest;
searchReq.send(null);
waitingreq='';
lastreq=curreq;
} else waitingreq=curreq;
return;
}
//Called when the AJAX response is returned.
function handleSuggest() {
if (searchReq.readyState == 4) {
if (document.getElementById('bbb_suggest') == null) return;
var ss = document.getElementById('bbb_suggest');
ss.innerHTML = searchReq.responseText;
}
// fire it again, if waitingrequest which is not yet serviced
if (waitingreq!='' && waitingreq!=lastreq && (searchReq.readyState==4 || searchReq.readyState==0)) {
searchReq.open('GET',waitingreq,true);
waitingreq='';
searchReq.onreadystatechange=handleSuggest;
searchReq.send(null);
}
return;
}
Comment 2•18 years ago
|
||
I don't understand what you're saying. We do kill the existing request and issue a new one if it hasn't returned by the time the next character is typed. This bug is really confusing though, so I'm not sure what you're looking for.
Feel free to renominate once this is confirmed.
Flags: blocking-firefox3?
(In reply to comment #2)
> I don't understand what you're saying. We do kill the existing request and
> issue a new one if it hasn't returned by the time the next character is typed.
This appears to break when the server's answers are coming slowly or later than expect and when the user has typed faster.
Sorry, I cannot measure exact times. Perhaps, to test the effect, you can slow down a server and check your software again.
In my case, that server is answering via a VPN connection.
Hi,
I do experience the same problem here. Scenario:
* I wrote a search plugin for an e-commerce site
* I wrote a suggestion API
* The API parses the HTML of the search result of the external website and returns a json string
The Api needs about 600ms to 1.3s to respond, even if I stop typing, the results are never displayed in firefox.
I fixed that issue for me with implementing memcache in my API after 2 days of trying to fix my code which was not broken in the end. ;-)
Comment 5•16 years ago
|
||
I can see it too with search terms which seem to be rarely used with the Answers.com search engine. Sometimes the auto-suggestion is not shown up. You only have to type the following sequence:
1. Type "f" and wait for the suggestion (even sometimes doesn't show up)
2. Type "ire" quickly and wait => no popup
3. Type "f" and wait => no popup
4. Type "o" and wait => popup
Confirmed with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.3pre) Gecko/20090813 Shiretoko/3.5.3pre ID:20090813031642
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: x86 → All
Version: unspecified → 2.0 Branch
In my AJAX-applications (not Firefox-related), I use the following mechanism to overcome slow server response problems:
My application always checks the latest server response content "on keypress". If the server response - which always contains a copy of the actually received string - is unequal to the _current_ application input (for example, when a last character was typed too quickly and not yet sent to the server), then my check routine triggers a new ajax request to the server inside the keypress procedure.
Ajax routines with that patch work very reliably in my environments.
(In reply to comment #6)
> In my AJAX-applications (not Firefox-related), I use the following mechanism to
> overcome slow server response problems:
code in https://bugzilla.mozilla.org/show_bug.cgi?id=392633#c1 comment 1
Comment 8•10 years ago
|
||
With no comment in the last 6 years, I don't think this is still a problem.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•