Closed Bug 1508252 Opened Last year Closed Last year

LeftArrow in composition mangles the text on macOS

Categories

(Core :: Widget: Cocoa, defect, P3)

63 Branch
defect

Tracking

()

VERIFIED FIXED
mozilla66
Tracking Status
firefox63 --- wontfix
firefox64 --- wontfix
firefox65 --- verified
firefox66 --- verified

People

(Reporter: danburzo, Assigned: m_kato)

Details

(Keywords: inputmethod)

Attachments

(3 files)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:63.0) Gecko/20100101 Firefox/63.0

Steps to reproduce:

Open the attached testcase (a simple textarea containing text) and perform these steps:


1. Place the cursor directly after `ipsum` (no space)
2. Using the Hiragana keyboard, type `sensei`
3. Press `LeftKey` repeatedly



Actual results:

Text gets repeated over and over, eating away at the rest of the textarea content.
Reproducible on Firefox Nightly 65.0a1 (2018-11-22), Firefox 64.0b12 and on 63.0.3 on Mac OS X 10.13.
Status: UNCONFIRMED → NEW
Component: Untriaged → Layout: Text and Fonts
Ever confirmed: true
Product: Firefox → Core
This can also be reproduced with the Katakana keyboard. Given that it seems to be a problem with how we interact with the platform IME, I think this more likely belongs in Widget than Layout; moving to that component. (Could also be an Editor issue, possibly?)
Component: Layout: Text and Fonts → Widget: Cocoa
Makoto, is this something that you could look into?
Flags: needinfo?(m_kato)
Priority: -- → P3
If not urgent, I can take this since I can reproduce it.  I will investigate this on 66 cycle since I am busy for GV 64.
Assignee: nobody → m_kato
Flags: needinfo?(m_kato)
Keywords: inputmethod
I can also reproduce this, but interestingly, Google Hiragana keyboard doesn't hit this issue.
This seems to be that SetMarkedText with replacement range doesn't set valid selection for start composition.
Attachment #9029655 - Attachment mime type: application/octet-stream → text/plain
This issue is e10s only.

Even if calling SetSelection, it doesn't reset selection cache in
TextInputHandler.  Since selection cache is updated by OnSelectionChange
asynchronous, we should set temporary range when having replacement range.

Also, even if marking dirty doesn't fix this issue. Content cache may return
other range such as caret position instead of replacement range by SetSelection.
Pushed by m_kato@ga2.so-net.ne.jp:
https://hg.mozilla.org/integration/autoland/rev/6adaa75e18dd
Set temporary range when replacement range is available. r=masayuki
https://hg.mozilla.org/mozilla-central/rev/6adaa75e18dd
Status: NEW → RESOLVED
Closed: Last year
Resolution: --- → FIXED
Target Milestone: --- → mozilla66
Is this something we should consider for uplift to Beta?
Comment on attachment 9030036 [details]
Bug 1508252 - Set temporary range when replacement range is available. r?masayuki

[Beta/Release Uplift Approval Request]

Feature/Bug causing the regression: None

User impact if declined: When using default Japnaese IME of macOS, text is often duplicated when using LeftArrow key.

Is this code covered by automated tests?: No

Has the fix been verified in Nightly?: Yes

Needs manual test from QE?: No

If yes, steps to reproduce: Open the attached testcase (a simple textarea containing text) and perform these steps:

1. Place the cursor directly after `ipsum` (no space)
2. Using the Hiragana keyboard, type `sensei`
3. Press `LeftKey` repeatedly

List of other uplifts needed: None

Risk to taking this patch: Low

Why is the change risky/not risky? (and alternatives if risky): Set expected start and end offset of composition as temporary.  Also, this code is used on IME only (Japanese, Chinese and Koren)

String changes made/needed: No
Flags: needinfo?(m_kato)
Attachment #9030036 - Flags: approval-mozilla-beta?
Flags: qe-verify+
Comment on attachment 9030036 [details]
Bug 1508252 - Set temporary range when replacement range is available. r?masayuki

[Triage Comment]
Fixes duplicated text after hitting the LeftArrow key when using the macOS Japanese IME. Approved for 65.0b6.
Attachment #9030036 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
I’ve reproduced this issue with Fx 65.0a1 (20181119220031) on macOS 10.13.
This is no longer reproducible with Fx 65.0b6 (20181220042023) and Fx 66.0a1 (20181219045530) on macOS 10.13 and macOS 10.14.
Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.