642402 - Characters not being typed if synchronous XHR on onkeyup

Status: UNCONFIRMED

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Karel Jára]

User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0
Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0

I think that this must be a bug in Firefox 4 because in Chrome this definitely works perfect. The problem is that if I have an synchronous XHR on onkeyup, then if you are writing characters too quickly, they are not actually written. Those characters which were typed during the XHR being processed are not there.

I’m adding link to this video. http://www.screenr.com/V3Q
This is my own script where there is XHR on onkeyup which looks up the database for existence of the string written. If the string already exists in DB, it makes the input text go red. I wrote words acknowledge, acrobat, analysis, adaptation, across and then once more analysis. As you can see, there are characters missing, they were not registered because of ongoing XHR.

Reproducible: Always

Steps to Reproduce:
1. Place a synchronous XHR on onkeyup of an input field.
2. Write characters in that input field.
Actual Results:  
Some characters are not registered.

Expected Results:  
Every single character typed should be registered and written in the field, at least with delay but should be there.

Comment 1

[Boris Zbarsky [:bzbarsky]]

smaug, do we suppress key events entirely during a sync xhr, or just queue them up?

Karel, per current HTML5 spec I think key input during a sync XHR is supposed to be ignored, fwiw.

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

If some keydown/press/up 'transaction' is being prosessed, events related
to that are queued. But new keydown/press/up 'transactions' aren't.
That was added just to not break some existing web site.
I'd like to get rid of even that, since while XHR is running, we just shouldn't
queue/process any key events, IMO.

(Well, actually I'd like to allow sync XHR only in Workers)

I can't now find my tests for xhr+keyevents, but at some point
webkit did queue all the events, but the event ordering was wrong
(keyup and keypress events were randomly in wrong order, IIRC)

Comment 3

[Karel Jára]

Well, OK. The thing is that I’ve been playing around with this and trying to
use sync XHR because when I used async, there comes a problem that when I’ve
written the whole word, I can never know, which of the XHR results comes last
and therefore is shown. I’ve experienced that when I wrote the whole word
“analysis”, which is in my database and so should show red, it remained black
because the last result that came wasn’t for “analysis” but e.g. for “analys”
which of course is not in DB, so the input field text remained black. I know
that this is not forum for solving problems of my own applications but I think
that this might be another bug because it never happened in Chrome, Opera, IE
or any other browser that I tried that the result of some former async XHR
would come after the last one and therefore overwrite it. Of course, by their
nature, async XHRs might not give results in order in which they were
triggered. But why this happens only in Firefox? Do you think I should file a
bug on this or is it my problem?

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

Ok, if the problem doesn't happen in any other browsers, we may need to
change our behavior.
 
But still about sync XHR. You do know that it is bad for user experience?
What if the network connection has problems and each sync XHR takes 10
seconds.
You could use async XHR and just abort() the ones which aren't needed anymore.
Or keep some list of XHRs in your page and listen load events only from the
most recent XHR.

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

Just tested, even the latest Chrome seems to mess up with event ordering pretty
badly, so any complex scrips couldn't rely on keyevent to work properly
with sync XHR either.

And Opera has similar problems, but it seems to change event ordering in a 
different way.

Comment 6

[BugBot [:suhaib / :marco/ :calixte]]

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.

Comment 7

[Kris Maglione [:kmag]]

I'm not sure there's an obvious fix for this other than not using sync XHRs from key event handlers. Handling the ordering of async responses from the client side may require some extra work, but handling processing key events while a key event handler is blocked on a sync XHR is even harder. And the user experience of blocking each key event on a sync XHR is just awful.