Closed Bug 1553852 Opened 3 years ago Closed 2 years ago

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

Categories

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

Desktop
All
defect

Tracking

()

RESOLVED FIXED
mozilla69
Tracking Status
firefox69 --- fixed

People

(Reporter: twisniewski, Assigned: edgar)

References

(Blocks 1 open bug, )

Details

(Keywords: inputmethod, reproducible)

Attachments

(1 file)

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.

Blocks: shadowdom

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

OS: Unspecified → All
Hardware: Unspecified → Desktop

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

Priority: -- → P2

(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.

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

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

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.

(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.

Flags: needinfo?(masayuki)

(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.

Flags: needinfo?(masayuki)
Component: DOM: Core & HTML → Editor
Pushed by echen@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/b7d6d747c7b9
Mark eCompositionChange as composed event; r=smaug

(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.

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla69
You need to log in before you can comment on or make changes to this bug.