1181501 - eKeyPress event should be fired in XP level and dispatched with preceding eKeyDown event in same event loop

Status: NEW

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

Description

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Currently, NS_KEY_DOWN and NS_KEY_PRESS are dispatched from widget separately. However, this causes hacky handling of preventDefault() of keydown event.
http://mxr.mozilla.org/mozilla-central/source/dom/ipc/TabChild.cpp?rev=e17e313a3066&mark=2544-2549#2539

I think that NS_KEY_DOWN_PRESS should be created and widget should dispatch it with enough information for dispatching both keydown event and keypress event.

Then, we can make better consistency between platforms and reduce number of IPC.

I think that we should fix this bug only with TextEventDispatcher here. Then, fixing bug 1137560 will fix this bug on all platforms automatically.

Comment 1

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

From widget point of view:

On WIndows, we can fix this simply because NativeKey peeks enqueued messages when it handles WM_KEYDOWN.

On Linux, modern IME works asynchronously (if IME handles key events synchronously, we can fix it simply). First, we receive GDK_KEY_PRESS and we send it to IME. Then, async IMEs returns "consumed" immediately without any text input. Then, we store the posted key event for the further processing. Then, same event will be sent by IME and we send same event to IME again. Then, IME sends composition events to let us know the inputting text. So, in the latter timing, we could fix this.

On macOS, like Linux, we receive a keyDown: call. Then, we notify its super class of the event to let IME know the event. Then, IME will call insertText: synchronously. So, we can fix this simply.

I'm not sure about Android. Makoto-san, do you know?

Comment 2

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Note that we cannot remove the IPC for eKeyPress because eKeyPress will keep needed by widget to dispatch isolated text input especially on Windows.

Comment 3

[Makoto Kato [:m_kato]]

As Android OS, it has ACTION_DOWN and ACTION_UP only. Android's widget dispatches eKeyPress after eKeyDown. If eKeyPress is dispatched automatically on content process, we can remove this emulation.

When using physical keyboard, https://searchfox.org/mozilla-central/rev/95935109bbbd4a39d612a917e59025f9c81f9d76/widget/android/GeckoEditableSupport.cpp#547
When using IME even if direct input, https://searchfox.org/mozilla-central/rev/95935109bbbd4a39d612a917e59025f9c81f9d76/widget/android/GeckoEditableSupport.cpp#960 (no composition only)

But, actually, we dispatch it on content process. So it may be another case.

Comment 4

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Thank you. I'll suggest to make us give higher priority to this bug.