- From: drwez <notifications@github.com>
- Date: Tue, 11 Jul 2023 08:42:48 -0700
- To: w3c/uievents <uievents@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
Received on Tuesday, 11 July 2023 15:42:54 UTC
This bug is specifically about the legacy `keypress` event, and by extension the legacy `charCode` attribute on that event - to encounter the `keypress` brokenness previously described the user would have to be (1) typing emoji or other non-BMP characters (2) using a browser with broken `charCode` for non-BMP and (3) into a web-site that is actively processing `keypress.charCode` to receive characters. The bug you link to is with "input" events being generated incorrectly and then handled unusually (it sounds like the single-surrogate DOMStrings are being treated as a complete Unicode code-point, somewhere in rust-dominator) and appears to be on Windows, not macOS. It is the case that `input` as currently defined should only ever report complete Unicode characters in `data` and fixing that should be safe from a backward-compatibility perspective. -- Reply to this email directly or view it on GitHub: https://github.com/w3c/uievents/issues/346#issuecomment-1631062414 You are receiving this because you are subscribed to this thread. Message ID: <w3c/uievents/issues/346/1631062414@github.com>
Received on Tuesday, 11 July 2023 15:42:54 UTC