1553852 - contenteditable items in a shadow root do not accept IME input from MacOS

Status: RESOLVED FIXED

(Core :: DOM: Editor, defect, P2)

Description

[Thomas Wisniewski [:twisniewski][PTO until Mar.16]]

The MacOS keyboard IME for Chinese text does not seem to work for contenteditable elements within a shadow root (the IME works fine for contenteditable elements not in a shadow root).

This can be seen on this test-case or even on the MDN page for contenteditable.

Comment 1

[Alice0775 White]

I can reproduce the issue on Nightly69.0a1 Windows10 MS-IME and ATOK.

Comment 2

[Hsin-Yi Tsai (she/her)[:hsinyi]]

Do we know if this is a recent regression? I'm asking simply because ATOK reminds me of a 68 regression bug 1549930.

Comment 3

[Hsin-Yi Tsai (she/her)[:hsinyi]]

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #2)

Do we know if this is a recent regression? I'm asking simply because ATOK reminds me of a 68 regression bug 1549930.
Okay, seems not related to bug 1549930. It is reproducible on firefox 66.

Comment 4

[Edgar Chen [:edgar]]

I found that HTMLEditor didn't receive eCompositionChange event, but not sure if it is related.

Comment 5

[Edgar Chen [:edgar]]

Oh, I just found that the mComposed flag of eCompositionChange event is false, so it could not cross the boundary of shadow DOM.

Comment 6

[Edgar Chen [:edgar]]

We could fix this issue by marking eCompositionChange event as a composed event. However, we plans to deprecate eCompositionChange event which is a gecko specific event, so maybe we should try to use eCompositionUpdate in HTMLEditor instead.

Comment 7

[Edgar Chen [:edgar]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=7345a31a1b1f73923ef86b70a6765b57a3e2f420

Comment 8

[Edgar Chen [:edgar]]

(In reply to Edgar Chen [:edgar] from comment #6)

We could fix this issue by marking eCompositionChange event as a composed event.

I decided go with this way because there are some test failure after moving to eCompositionUpdate (comment #7), and it probably requires me more time to investigate.

However, we plans to deprecate eCompositionChange event which is a gecko specific event, so maybe we should try to use eCompositionUpdate in HTMLEditor instead.

Is this something we want to do for the long term? If yes, I could file a follow-up bug for it.

Comment 9

[Edgar Chen [:edgar]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=eaefbfbc8f98057cdc86a3cfd1fe8245471a202e

Comment 10

[Edgar Chen [:edgar]]

Attachment: Bug 1553852 - Mark eCompositionChange as composed event;

Comment 11

[Edgar Chen [:edgar]]

(In reply to Edgar Chen [:edgar] from comment #8)

However, we plans to deprecate eCompositionChange event which is a gecko specific event, so maybe we should try to use eCompositionUpdate in HTMLEditor instead.

Is this something we want to do for the long term? If yes, I could file a follow-up bug for it.

It seems "yes" per https://phabricator.services.mozilla.com/D33387#989677.

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/b7d6d747c7b9
Mark eCompositionChange as composed event; r=smaug

Comment 13

[Edgar Chen [:edgar]]

(In reply to Edgar Chen [:edgar] from comment #11)

(In reply to Edgar Chen [:edgar] from comment #8)

However, we plans to deprecate eCompositionChange event which is a gecko specific event, so maybe we should try to use eCompositionUpdate in HTMLEditor instead.

Is this something we want to do for the long term? If yes, I could file a follow-up bug for it.

It seems "yes" per https://phabricator.services.mozilla.com/D33387#989677.

Filed bug 1556336.

Comment 14

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/b7d6d747c7b9