Bug 170368 - The keypress event is never fired in Sogou IME
Summary: The keypress event is never fired in Sogou IME
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: HTML Editing (show other bugs)
Version: Safari 10
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on: 169209 170369 170370
Blocks:
  Show dependency treegraph
 
Reported: 2017-03-31 17:00 PDT by Beth Dakin
Modified: 2019-02-06 22:08 PST (History)
9 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Beth Dakin 2017-03-31 17:00:42 PDT
This bug represents this action item: The keypress event is never fired in Sogou IME 

+++ This bug was initially created as a clone of Bug #169209 +++

I tested this on:

* Safari Technology Preview Release 23 (Safari 10.2, WebKit 12604.1.5)
* Safari Version 10.0.3 (12602.4.8)

I am using the Sogou IME (http://pinyin.sogou.com/mac/).

I am using this JS fiddle to log events, but any event logger will show this: https://jsfiddle.net/c1g6rahm/2/

In a content editable, press a punctuation character (eg. the key '.' to get '。', ',' to get ',', 'Shift+1' to get '!' - notice they are full width).

Obtained event trace:
1. textInput
2. input
3. keydown - 229 (WIN_IME key)
4. keyup - 188 (in this case I pressed ',')

This is problematic for a number of reasons:
1. There is no compositionstart/compositionupdate/composition end events, which there should be when using keydown WIN_IME
2. The textInput/input events are not between keydown/keyup, which they should be (they are when pressing regular ASCII/latin characters)
3. There is no keypress event fired. For example, Chrome fires a keypress with keycode 65292 for ',' and with keycode 12290 for '。'

The combination of these make it very hard to detect that these specific characters were selected without relying on the contents of the contenteditable. This also diverges from the spec at https://w3c.github.io/uievents/#events-composition-key-events.
Comment 1 Alexey Proskuryakov 2017-04-04 16:55:24 PDT
This is (or at least was) intentional behavior. We only fire keypress events when inline input is not in use. 

Is there a formal spec that Chrome behavior conforms to? Do other browsers agree?
Comment 2 Ryosuke Niwa 2017-04-04 19:15:32 PDT
(In reply to Alexey Proskuryakov from comment #1)
> This is (or at least was) intentional behavior. We only fire keypress events
> when inline input is not in use. 
> 
> Is there a formal spec that Chrome behavior conforms to? Do other browsers
> agree?

So I think the problem here is that we're not firing either composition event or keypress instead of either.
Comment 3 Ryosuke Niwa 2017-08-20 15:40:02 PDT
Wenson, didn't you fix a bug like this?
Comment 4 Wenson Hsieh 2017-08-20 15:44:28 PDT
(In reply to Ryosuke Niwa from comment #3)
> Wenson, didn't you fix a bug like this?

I think you might be thinking of https://bugs.webkit.org/show_bug.cgi?id=164369 or https://bugs.webkit.org/show_bug.cgi?id=164324, which are a bit different in that they're concerned with input and composition events rather than key events.
Comment 5 Lucas Forschler 2019-02-06 09:18:41 PST
Mass move bugs into the DOM component.
Comment 6 Ryosuke Niwa 2019-02-06 22:08:16 PST
This is an editing bug.