New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 639481 link

Starred by 4 users
Status: WontFix
Owner: ----
Closed: Nov 23
Cc:
shuchen@chromium.org
█ suzhe@chromium.org
tapted@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug



Sign in to add a comment

On going composition state is not reset when <input> is removed.

Project Member Reported by ekaramad@chromium.org, Aug 19 2016 
Version: 52.0.2743.116 (Official Build) (64-bit)
OS: Mac

What steps will reproduce the problem?
(1) Open chrome to the attached html file. There are two rows for <input>s A and B.
(2) Enable some IME language (e.g., Pinyin/Chinese)
(3) Press 'Remove in...' for <input> A so that the <input> is removed in 5 seconds (change the delay if required).
(4) Before <input> A is removed focus it and press 'a' a couple of times (say 5 times).
(5) The IME drop-down list shows options for composition the first one being 啊啊啊啊啊 and the text inside the <input> A (before committing) is 5 underlined 'a's.
(6) Now wait until <input> A is removed.
(7) Focus <input> B and press 'a' again.

What is the expected output?
The IME window only shows 啊 as the first option and shows exactly one underlined 'a' inside the <input> (it ignores the previous 5 uncommitted 'a's).

What do you see instead?
The underlined text has 6 'a's now and the first composition option is 啊啊啊啊啊啊.

We should somehow reset the IME state after such scenarios, i.e., maybe when it is reset to ui::TEXT_INPUT_TYPE_NONE (after <input> A is removed) we should remove all ongoing compositions.

This behavior was not observed on Ubuntu. Seems to be a Mac only issue. I assume this is a bug?
repro_steps.mov
1.9 MB Download

Comment 1 by erikc...@chromium.org, Aug 20 2016 

Hi, this bug is in the Mac team's triage queue, and we have no idea what to do with it:

We can:
1) Ignore bugs with the UI>Input>Text>IME component.
2) Add another component?
3) Mark it as available and hope that someone looks at available UI>Input>Text>IME bugs?

Who actually works on IME now?

Comment 2 by shuchen@chromium.org, Aug 20 2016

Cc: tapted@chromium.org
Status: Available (was: Untriaged)
I'm maintaining IME/IMF on CrOS/Win/Linux/Mac.

For Mac/IME specific issues, I think it is also in tapted@'s radar.

ekaramad@, can you please confirm whether this issue repros on other platforms? Thanks!

Comment 3 by ekaramad@chromium.org, Aug 20 2016 

Attached the missing HTML file for verification.

shuchen@: It does not happen on Linux, so I guess Win/ChromeOS should be good as well. I will verify them soon and update the bug.
inputs2.html
1.1 KB View Download
Project Member

Comment 4 by sheriffbot@chromium.org, Aug 21 2017

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 5 by lgrey@chromium.org, Aug 22 2017

Status: Available (was: Untriaged)
shuchen@ is this still your area, or is there someone better to pass it along to?

Comment 6 by lgrey@chromium.org, Aug 22 2017

Labels: -Hotlist-Recharge-Cold

Comment 7 by robliao@chromium.org, Aug 22 

Archiving old bugs that haven't been actively assigned in over a year.

If you feel this issue should still be addressed, feel free to reopen it or to file a new issue. Thanks!

Comment 8 by ajha@chromium.org, Nov 23

Labels: Hotlist-DesktopUIChecked
Status: WontFix (was: Available)
**Mass UI Triage**

We were unable to reproduce this bug on the latest canary 72.0.3618.0 on Mac OS 10.13.6. If this bug still reproduces for you, please reopen or file a new issue. Thanks!
►

Sign in to add a comment