Closed Bug 1390124 Opened 7 years ago Closed 3 years ago

macOS: `compositionstart` and `compositionend` events both triggered _after_ composing accented latin character

Categories

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

Product:
Core
Component:
DOM: UI Events & Focus Handling
Version:
54 Branch
Platform:
Desktop
macOS
Type:
defect

Tracking

()

Status:
RESOLVED WONTFIX
Tracking Flags:
Tracking Status
firefox55 --- wontfix
firefox56 --- wontfix
firefox57 --- wontfix

People

(Reporter: danburzo, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: inputmethod)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:54.0) Gecko/20100101 Firefox/54.0 Build ID: 20170628075643 Steps to reproduce: On macOS: 1. Listen to the `compositionstart` and `compositionend` events on any element that accepts input (contenteditable, textarea, etc.) 2. Press and hold the "a" key on your keyboard to invoke the Accent Menu in macOS 3. While holding the "a" key, press a numeric key (e.g. "1") to generate an accented letter Actual results: Both `compositionstart` and `compositionend` events are fired _after_ pressing the numeric key / finishing the composition. Expected results: `compositionstart` should fire when the Accent Menu is invoked (Step 2). Note: neither Chrome nor Safari currently trigger CompositionEvents for the macOS Accent Menu. Relevant issue for W3C Editing Task Force: https://github.com/w3c/editing/issues/132
Component: Untriaged → Editor
Product: Firefox → Core
Component: Editor → Widget: Cocoa
Keywords: inputmethod
On second thought, it may be a better idea not to trigger composition events at all for this, and instead fix this as part of supporting the Input Events Level 2 spec? https://w3c.github.io/input-events/ Pressing `a` would trigger beforeinput/input events of inputType=insertText, and composing it to `á` would trigger beforeinput/input events of inputType=insertReplacementText, as currently implemented by Safari. (You can use this webpage to observe the UI Events triggered by various browsers in response to user input: https://danburzo.github.io/input-methods/ )
status-firefox55: --- → wontfix
status-firefox56: --- → wontfix
status-firefox57: --- → wontfix
Priority: -- → P5

Moving all open keyboard/IME handling bugs to DOM: UI Events & Focus Handling component.

Component: Widget: Cocoa → DOM: UI Events & Focus Handling

According to bug 1709152, this incompatibility causes not allowing to cancel input from it from beforeinput event listeners. So, we should fix this.

Assignee: nobody → masayuki
Blocks: editor-blink-compat
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Priority: P5 → P3

Sorry for the spam. I misunderstood this bug report. And I couldn't reproduce this bug at least on Big Sur. Let's mark this as WFM if this is not reproducible on older macOS too.

Status: ASSIGNED → UNCONFIRMED
Ever confirmed: false
Priority: P3 → P5
Assignee: masayuki → nobody
Blocks: 1709152
Flags: needinfo?(masayuki)
No longer blocks: 1709152
Flags: needinfo?(masayuki)
Flags: needinfo?(masayuki)

compositionstart should fire when the Accent Menu is invoked (Step 2).

Ah, this is impossible because Cocoa does not notify us anything of showing the popup.

And currently, we stop dispatching a set of composition events. And the new behavior is exactly same as Chrome. On Sierra, High Sierra and Mojave, you see events in this order at pressing a numeric key:

  1. keydown for the numeric key
  2. keyup for the numeric key (without keypress for the numeric key, this means that this key press didn't insert a character directly)
  3. beforeinput whose data is the accented character (this is cancelable)
  4. input whose data is the accented character

On Catalina and Big Sur, you see the event order as #1 -> #3 -> #4 -> #2. (I.e., beforeinput and input are fired before keyup).

Ideally, at least the keydown event's keyCode should be 229 and key should be Process since it's consumed by the native IME. However, only on Safari, the keycode is set as properly. This could be fixed by bug 1338460 in the future, but I'm not sure whether it's true.

Anyway, this is WONTFIX due to the IME's behavior in the native IME event level.

Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Flags: needinfo?(masayuki)
Resolution: --- → WONTFIX
Severity: normal → S3
Depends on: 1709152
OS: Unspecified → macOS
Hardware: Unspecified → Desktop
See Also: → https://bugzilla.mozilla.org/show_bug.cgi?id=1338460
You need to log in before you can comment on or make changes to this bug.