1524986 - Request rerouting of keyboard events received after giving away focus (blur)

Status: RESOLVED WONTFIX

(Core :: DOM: UI Events & Focus Handling, enhancement, P2)

Description

[Henri Sivonen (:hsivonen)]

(This is not for the first round of implementation of event delivery to out of process iframes.)

An event handler in a content process can react to keyboard events by focusing an iframe in the document that the event handler is in. If there are multiple key events in-flight before the focus change has propagated to the APZ infrastructure, keyboard events issued after the one that caused a focus change can be sent to the wrong process (the one that gave away focus). We need to introduce a way for a process that believes it no longer has focus to request rerouting of keyboard events it receives.

Comment 1

[Henri Sivonen (:hsivonen)]

APZ infrastructure is no longer relevant. However, there's still a chance that a second keyboard event gets sent to content before the chrome main thread has received a message requesting focus move triggered by the first keyboard event.

It seems to me that requesting rerouting will misorder keystrokes, which seems worse than dropping some.

AFAICT, if we don't want to drop keystrokes and don't want to reorder them, we'd need to make the content process acknowledge each keystroke and make the chrome process queue up keystrokes if there's an outstanding unacknowledged one and send the next one from the queue upon acknowledgement. Even when focus isn't moving, this would cause a queue build-up if the IPC roundtrip time is greater than the time between keystrokes. Is there a scenario where that could occur with a human actually pressing keys?

nika, do you have opinions on how to proceed?

Comment 2

[Nika Layzell [:nika] (ni? for response)]

I'm not sure about the situation with the queue building up but it definitely seems unfortunate.

I think it would be possible to keep ordering while continuously sending down events. In effect there would be a deque of keyboard events dispatched to content and an ack, but parent wouldn't wait for an ack to send the next one. When the child causes a focus change, the parent would take the queue and re-dispatch it to the new content process, and the child would discard incoming events from that epoch.

We'd have to wait for the current queue to flush before changing focus from another process, but that might be OK.

Comment 3

[Henri Sivonen (:hsivonen)]

Looks like TabChild already responds to key events if aEvent.WantReplyFromContentProcess() returns true.

smaug, how common is it for keyboard events to want a reply? Would it be bad to make all of them want a reply? What does the chrome process currently do if another keyboard event comes in before a reply to the previous one has been received?

Comment 4

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

The issue is that parent process handles key events which are waiting for the reply differently.
https://searchfox.org/mozilla-central/rev/201450283cddc9e409cec707acb65ba6cf6037b1/layout/base/PresShell.cpp#7754-7763,7765-7766,7778

Waiting for reply isn't bound to new incoming events.

Comment 5

[Henri Sivonen (:hsivonen)]

I'll write a test case for this to see how easy it is to trigger the situation with human-generated key presses (to get an idea of how serious this issue is).

Comment 6

[Henri Sivonen (:hsivonen)]

(In reply to Henri Sivonen (:hsivonen) from comment #5)

I'll write a test case for this to see how easy it is to trigger the situation with human-generated key presses (to get an idea of how serious this issue is).

I wrote https://hsivonen.fi/keyboard-top.html

The three levels of documents all log keydown and keyup events. The topmost frame focuses the middle frame upon "e" keydown. Upon gaining focus, the middle frame immediately focuses the inner frame.

When trying to press keys manually, I'm not able to trigger any misbehavior. Everything works as expected: The middle frame logs nothing, the top frame logs keydown for "e" and the inner frame logs keyup for "e" as well as subsequent keydowns and keyups.

When using a program that simulates a sequence of keystrokes, both non-Fission and Fission handle all the keydown and keyup events on the top level with the focus still on the top level afterwards. While the behavior of the focus staying on the top level afterwards in the synthetic case even in non-Fission is weird, it seems so far that we probably don't need any new code here for Fission reasons.

I'll try on Mac and Linux, still.

Comment 7

[Henri Sivonen (:hsivonen)]

Marking WONTFIX, since IPC appears to be so fast relative to being able to generate events by actually pressing keys that it the concern speculated about when filing this isn't a real problem, so let's not introduce complexity to deal with a non-problem.