Open Bug 1602694 Opened 5 years ago Updated 3 years ago

No keypress event for control characters is fired on Windows

Categories

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

Product:
Core
Component:
DOM: UI Events & Focus Handling
Version:
71 Branch
Platform:
All
Windows
Type:
defect

Tracking

()

People

(Reporter: mseele, Unassigned)

References

(Blocks 2 open bugs)

Details

(Keywords: parity-chrome)

Attachments

(1 file)

Bug 1602694 - Make `NativeKey::HandleCharMessage()` dispatch `eKeyPress` event when `WM_CHAR` is sent to input a control character except null r=m_kato!,smaug!
47 bytes, text/x-phabricator-request
Details | Review

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36

Steps to reproduce:

Key Press "ALT" and key click "029" over numpad into https://w3c.github.io/uievents/tools/key-event-viewer.html

Actual results:

No keypress event for character 29 ( / GS group separator) is shown

Expected results:

Keypress event for character 29 ( / GS group separator) should be shown

Doing the same thing under chrome (Version 78.0.3904.108) works.

This is needed to parse GS1 Barcodes with FNC1 separators (is encoded as GS group separator / character 29) correct within the browser. Please see https://www.barcodefaq.com/1d/gs1-128/ & https://www.barcodefaq.com/ascii-chart-char-set/ for more details.

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → DOM: Events
Product: Firefox → Core

Seems like the event is even fired in Internet Explorer & Edge. I would agree that it seems more like a bug than an enhancement request. Changed it to defect.

Type: enhancement → defect
Priority: -- → P3

Any news on this? This is a serious issue that makes firefox unusable for us right now.
Is there anything is can help you with this bug?

Masayuki, do you have ideas how we can fix this?

Severity: normal → S3
Flags: needinfo?(masayuki)

Hmm, it's wired behavior of Chrome.
https://www.w3.org/TR/uievents-key/#keys-unicode

In the UI Events spec, control character shouldn't be exposed to the web. Let me check Chromium's code...

Status: UNCONFIRMED → NEW
Component: DOM: Events → DOM: UI Events & Focus Handling
Ever confirmed: true
Flags: needinfo?(masayuki)

Hi, Gary, we discussed about non-printable characters for keyboard events for several years ago. At that time, the conclusion was that control characters shouldn't be exposed to the web. That's explicitly mentioned in the spec. However, Chromium exposes it with both KeyboardEvent.charCode and KeyboardEvent.key only when Chromium receives WM_CHAR directly (meaning without WM_KEYDOWN nor WM_SYSKEYDOWN).

Is this intentional behavior?

If so, UI Events spec should have additional note at least because this report makes me suspect that there are some web apps which depend on keypress events which let them know control character inputs.

Flags: needinfo?(garykac)

I'm not familiar with the history of control-character support in Chromium, so I don't know if it's intentional or not. But in any case the spec and browsers need to be consistent.

The |key| attribute is not allowed to have control characters, but the spec is not well defined about what to do when control keys are pressed (other than for a small set of special control character like "Backspace", "Tab", "Escape",... ).

When given a control character key press, should the browser:

(a) Ignore the key press altogether
(b) Generate a key press with some valid |key| value: (e.g., something like "Ctrl-029", like we do for "Enter")

The Chromium behavior described sounds incorrect since the |key| attribute should not contain control characters. But these events (at least some of them) appear to be useful to developers so (a) doesn't seem like a good general solution.

We took the (b) route for the few obvious control characters we knew we needed to support (listed above). We could add another one here for for the group separator, but we should consider a more general solution (something like "Control-029").

WDYT?

Flags: needinfo?(garykac) → needinfo?(masayuki)

Gary: Thank you for the reply.

Sounds reasonable to me, and just like ControlChar or something is also fine to me because parsing it to get a control character may make the web apps complicated, and when web apps want to access control character value directly, legacy charCode attribute set to the raw value (i.e., a control character's Unicode point) only in legacy keypress events is available.

On the other hand, I'm not sure whether such keypress event should cause beforeinput event, though. Chrome does not dispatch beforeinput event for it. Probably, the reason of not dispatching beforeinput event is, its editor does not insert the control character.

Flags: needinfo?(masayuki)

We should fix this for next ESR release.

Assignee: nobody → masayuki
Status: NEW → ASSIGNED
OS: Unspecified → Windows
Priority: P3 → P2
Hardware: Unspecified → All

(If you need bug fix on Linux/macOS too, let me know ASAP. The deadline of next ESR is soon.)

@masayuki thank you for working on this. We need a fix under windows/linux/macOS.

(In reply to mseele from comment #11)

@masayuki thank you for working on this. We need a fix under windows/linux/macOS.

Do you know how to test it on Linux and macOS without barcode scanner?

Flags: needinfo?(mseele)

Okay, I got it on macOS. I find "Unicode Hex input" IME.

Hmm, on Ubuntu, I can type a Unicode character after Ctrl + Shift + U, but it starts IME composition for waiting code point input. So, I'm still not sure how barcode scanner sends the character.

Flags: needinfo?(mseele)

And also we have bug 1098981, that anyway blocks some generated text input from HID. So, anyway we cannot support it on Linux for now.

Chrome dispatches keypress event for WM_CHAR message which is not following
WM_KEYDOWN message even if the character is a control character except null.
We should follow the behavior for web-compat of users who use barcode scanner
or something.

This patch makes NativeKey::HandleCharMessage() dispatches eKeyPress event
even when coming a control character, but different from Chrome, this patch
does not set the control character to KeyboardEvent.key since UI Events spec
explicitly refuses control characters in the attribute value.
https://www.w3.org/TR/uievents-key/#key-string
For making new path isolated from existing path, this patch adds new internal
KeyNameIndex for the keypress event which exposes a control character.

And also, this patch adds new API into nsITextInputProcessor and EventUtils
to test the keypress events exposing a control character. It shouldn't be
handled by editor for both backward compatibility and web-compat. I.e., \n
and \r shouldn't cause a line break in multiline editor and any control
characters shouldn't be inserted into any editor.

Summary: No keypress Event for GS group separator (0x1D) → No keypress event for control characters is fired on Windows

(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #12)

(In reply to mseele from comment #11)

@masayuki thank you for working on this. We need a fix under windows/linux/macOS.

Do you know how to test it on Linux and macOS without barcode scanner?

macOS works with "Unicode Hex input" IME like you described.

Under linux you need to press "control (left)" and then click the "bracket right" key.
This will generate the required keypress event.

(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #14)

Hmm, on Ubuntu, I can type a Unicode character after Ctrl + Shift + U, but it starts IME composition for waiting code point input. So, I'm still not sure how barcode scanner sends the character.

Please see the xev output under ubuntu:

KeyPress event, serial 37, synthetic NO, window 0x4000001,
root 0x1c5, subw 0x0, time 2205044, (-980,-166), root:(637,717),
state 0x10, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False

KeyPress event, serial 37, synthetic NO, window 0x4000001,
root 0x1c5, subw 0x0, time 2205044, (-980,-166), root:(637,717),
state 0x14, keycode 35 (keysym 0x5d, bracketright), same_screen YES,
XLookupString gives 1 bytes: (1d) ""
XmbLookupString gives 1 bytes: (1d) ""
XFilterEvent returns: False

KeyRelease event, serial 37, synthetic NO, window 0x4000001,
root 0x1c5, subw 0x0, time 2205052, (-980,-166), root:(637,717),
state 0x14, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False

KeyRelease event, serial 37, synthetic NO, window 0x4000001,
root 0x1c5, subw 0x0, time 2205052, (-980,-166), root:(637,717),
state 0x10, keycode 35 (keysym 0x5d, bracketright), same_screen YES,
XLookupString gives 1 bytes: (5d) "]"
XFilterEvent returns: False

(In reply to mseele from comment #17)

(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #12)

(In reply to mseele from comment #11)

@masayuki thank you for working on this. We need a fix under windows/linux/macOS.

Do you know how to test it on Linux and macOS without barcode scanner?

macOS works with "Unicode Hex input" IME like you described.

Under linux you need to press "control (left)" and then click the "bracket right" key.
This will generate the required keypress event.

Unfortunately, key presses with Ctrl key cannot expose control character information under current web standards.

Does your barcode scanner synthesize the key event with Ctrl key on Linux like comment 18?

Flags: needinfo?(mseele)

Under linux you need to press "control (left)" and then click the "bracket right" key.
This will generate the required keypress event.

Unfortunately, key presses with Ctrl key cannot expose control character information under current web standards.

Does your barcode scanner synthesize the key event with Ctrl key on Linux like comment 18?

Yes. Comment 18 is a xev recording from the barcode scanner. Works also in https://w3c.github.io/uievents/tools/key-event-viewer.html under chrome. Ctrl + ] works in chrome, does not work in firefox under linux.

Flags: needinfo?(mseele)

Sigh, that's really bad news. I should give up to fix this bug in next ESR due to deadline is coming and we need to violate web standards in some cases if we need to dispatch keypress events only for some special devices. I need to investigate this more before landing the patch and we need to discuss in UI Events WG.

Status: ASSIGNED → NEW
Priority: P2 → P3

Filed spec issue, but I still don't fine the condition when Chrome stops dispatching keypress event for control characters.

See Also: → https://github.com/w3c/uievents/issues/266

Hello, everyone.
I can also confirm that when scanning a GS1 Datamatrix code the "Group Separator" in Firefox is not evaluated. In Chrome and Internet Explorer it works fine.

Maybe this is also helpfull for you:

Here a link to screenshot-01:
https://www.directupload.net/file/d/5875/lhpkbmsz_png.htm

Here a link to screenshot-02:
https://www.directupload.net/file/d/5875/4go638mf_png.htm

Test-Data

Firefox:
rawScannerInput: 93;100;50;48;49;48;52;56;49;49;48;48;48;48;48;48;50;51;55;49;55;50;50;48;57;51;48;49;48;67;72;53;56;57;50;49;82;49;48;48;48;54;51;87;71;87;65;87;65;87;87;87;76;87;48;65;
convertedScannerInput: ]d201048110000002371722093010CH58921R100063WGWAWAWWWLW0A

Chrome:
rawScannerInput: 93;100;50;48;49;48;52;56;49;49;48;48;48;48;48;48;50;51;55;49;55;50;50;48;57;51;48;49;48;67;72;53;56;57;29;50;49;82;49;48;48;48;54;51;87;71;87;65;87;65;87;87;87;76;87;48;65;
convertedScannerInput: ]d201048110000002371722093010CH58921R100063WGWAWAWWWLW0A

Compare of both:
93;100;50;48;49;48;52;56;49;49;48;48;48;48;48;48;50;51;55;49;55;50;50;48;57;51;48;49;48;67;72;53;56;57; ;50;49;82;49;48;48;48;54;51;87;71;87;65;87;65;87;87;87;76;87;48;65;
93;100;50;48;49;48;52;56;49;49;48;48;48;48;48;48;50;51;55;49;55;50;50;48;57;51;48;49;48;67;72;53;56;57;29;50;49;82;49;48;48;48;54;51;87;71;87;65;87;65;87;87;87;76;87;48;65;

ASCII dez:
29 = GS (GroupSeparator)

Resetting assignee which I don't work on in this several months.

Assignee: masayuki → nobody

Hi,

I am responsible for the specifications and QA in a French software editor.
We provide our customers with data matrix USB reader to manage their assets and save time managing their stock movements.
Thus they cannot use Firefox anymore (official web browser in a lot of administrative units), it is a blocking issue for us.

Would it be possible to fix this issue in next ESR and/or standard release?

Kind regards

Michael

Masayuki:

Are you saying this is unfixable?

What is the reason we can't make our code work like Chrome?

Flags: needinfo?(masayuki)

There are some complicated and related issues:

  1. Chrome's behavior violates current web standard (UI Events)
  2. Chrome's behavior is inconsistent between platforms
  3. We stopped dispatching keypress events for non-printable keys because of a request from Google's search team.
  4. When we stopped dispatching them, we have experienced a lot of web-compat issues.
  5. Barcode scanner users are not majority of our users.
  6. Web apps can simulate the keypress event with listening to keydown events (it might be impossible on Windows, though)

So, once it'd be standardized, we could ship easier. Otherwise, we need to investigate and does exactly same behavior as Chrome for the other web apps which don't want to handle ASCII control character inputs. But doing it requires a lot of Nightly testers, but we've already lost such volume. So, the main problem is, whether we can take the risk or not right now. (In other wise, I guess that only fixing this bug, i.e., making it work with specific devices may be safer. But according to comment 11, we need to fix this for all platforms and devices. Of course, it's risky as I explained.)

Flags: needinfo?(masayuki)

Hi,
Do you have any information about this issue ?
As mseele said above, it prevents our customer to use Firefox for decoding GS1 datamatrix.

Any help to solve that would be appreciated.

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

Attachment

General

Creator:
Created:
Updated:
Size: