Closed Bug 1662265 Opened 4 years ago Closed 4 years ago

Some keyboard keystrokes are lost while synchronous server calls


(Core :: DOM: Networking, defect, P2)

78 Branch



86 Branch
Tracking Status
firefox80 --- wontfix
firefox81 --- wontfix
firefox82 --- wontfix
firefox86 --- fixed


(Reporter: l.miller, Assigned: sefeng)


(Blocks 1 open bug)


(Whiteboard: [necko-triaged])


(2 files, 1 obsolete file)

Attached file input.html

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:80.0) Gecko/20100101 Firefox/80.0

Steps to reproduce:

Open the attached html file with Firefox 78.0.2. Type fast ex. "1234567890" at the input field. Notice that some symbols are lost.

Other browsers (Chrome 84.0.4147.89, Internet Explorer 11.0.9600.17843, Edge 84.0.522.40, Safari 13.1.2.) does not have this bug.

Actual results:

Not all typed symbols do present at the input field.

Expected results:

Well, all typed symbols should present at the input field.

We know that syncronous server calls are not recommended but there are some use cases when they cannot be avoided. For example while a user typing we should validate the user input syncronously at server side, and either allow input or disallow it at keypress event handler.


I was also able to replicate the issue on my end. I'm using windows 10 pro, firefox nightly 82.0a1 (2020-09-04) (64-Bit), beta 81.0b4 and release 80.0. (does not happen in Crome)

I will move this over to a component so developers can take a look over it. If is not the correct component please feel free to change it to an appropriate one.

Thanks for the report.

Best regards, Clara.

Component: Untriaged → Keyboard Navigation
Ever confirmed: true
Component: Keyboard Navigation → DOM: Editor
Product: Firefox → Core

l.miller, it seems like it should be possible to design a UI that does not require that.

Olli, this is a bug caused by synchronous XMLHttpRequest having a nested event loop. Perhaps it's more feasible to fix this with e10s-multi?

Blocks: 978757
Flags: needinfo?(bugs)
Component: DOM: Editor → DOM: Networking

Yes, sync XHR causes Gecko to prevent user interaction events.
Note, last time I checked, all the browsers get input events in a weird way when sync XHR is running - missing events or in a wrong order (but that was awhile ago when I tested).

e10s-multi as such doesn't help here. What we could do is to let input events get queued, but not process any of them until the sync operation is done. That would be relatively easy to implement (in child processes) given that there is a separate queue for input events these days.

Flags: needinfo?(bugs)
Assignee: nobody → sefeng
Severity: -- → S3
Priority: -- → P2
Whiteboard: [necko-triaged]

There are two issues in our current setup

  1. Input events which are occurring in the same tab are going to be lost
    because sync XHR. We have event handling suppression for synx XHR, so input
    events are going to be discarded.

  2. Input events that are happening in another tab (same process as the
    synx XHR tab) are not going to be delayed. This is not correct since
    sync XHR should block the Javascript execution.

This patches fixes the above cases for when both TaskController and e10s are
enabled by suspending the InputTaskManager during sync XHR, which
delays the input event handling and keeps the events around.

This grants us the ability to rely on InputTaskManager to suspend
input events when needed.

Attachment #9180429 - Attachment is obsolete: true
Pushed by
Fix input events handling for sync XHR when both TaskController and e10s are enabled r=smaug
Pushed by
Fix input events handling for sync XHR when both TaskController and e10s are enabled r=smaug
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → 86 Branch
Regressions: 1682866
Regressions: 1683112
No longer regressions: 1682040

It is reported that the error is fixed at the version 86. We have checked up a Nightly build 87.0a1 and the error is still there. Should we check later versions? If yes then which ones?
Thank you.

Sorry, the fix is behind the dom.input_events.canSuspendInBCG.enabled pref, and it's currently disabled.

You need to log in before you can comment on or make changes to this bug.