Regression: the first input of CJK IMEs gets immediately entered when omnibox keyword mode is invoked
Reported by
innatere...@gmail.com,
Oct 19
|
||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.10 Safari/537.36 Steps to reproduce the problem: 1. Type bing.com in omnibox. The Tab-to-search icon appears at rightmost of omnibox. 2. Click the Tab-to-search icon or hit Tab key to enter keyword mode. 3. Switch to Japanese IME and type sushi. What is the expected behavior? すし (su+shi) are inputted, and all words remain underlined (i.e. not confirmed yet). What went wrong? ｓうし (s+u+shi) are inputted, with the ｓ already got confirmed. In CJK IMEs the typed alphabets (or phonetic symbols for traditional Chinese) 'suspend' to wait to be combined with subsequent alphabets/symbols to form a CJK word. They all keep being underlined until user hit Enter to confirm the combinations, only then is the whole string actually inputted. With this bug, when keyword mode is initialized, the first typed alphabet/symbol gets immediately 'entered' as-is without waiting to be combined. Did this work before? Yes Before Dev channel entered M71. Chrome version: 71.0.3578.10 Channel: dev OS Version: 6.1 (Windows 7, Windows Server 2008 R2) Flash Version: This is a re-filing of issue 890203 , which got closed due to lack of reproducibility on the developers side. However I continue to be able to reproduce with recent canaries on every computer I could get contact with. And TE team was also able to reproduce back in issue 890203 . So I am filing this again, first to verify whether this is still reproducible on TE's end as well with current Dev channel or even ToT, then in the hope that a second time triage could yield a more precise regression window to identify the correct culprit.
,
Oct 19
note there's some history here with crbug.com/890203 I am able to repro (Win10, Chrome Canary, Microsoft IMEs). I can take a look at OnTemporaryTextMaybeChanged that Mark suggested in the other bug, slightly lower priority than some other stuff if anyone wants to grab this. useful keyboard shortcuts: Win+Space to switch input methods; if they're both alphanumeric, note that Alt-Shift will switch between languages, and alt-~ will switch in and out of Hiragana IME.
,
Nov 4
Friendly ping. Is the source of the bug surely identified? How many days do we have before a fix merge to Beta branch become unwelcome?
,
Nov 8
The M71 Stable incoming reminder has just been dispatched on labeled bugs :/
,
Nov 12
,
Dec 10
,
Dec 17
,
Jan 14
Issue 921303 has been merged into this issue.
,
Jan 14
So it looks it already enters Stable? Wish we can get a fix soon.
,
Jan 14
,
Jan 14
Can someone please at least update this bug's various labels and apply to it a release blocker as matters stand? So it gets ATTENTION from managers. This bug is NOT BEING WORKED ON despite the Started status. And it has been three months.
,
Jan 15
krb@: maybe you'd like to take this. I just got back from a leave of absence. I bisected this on Mac to You are probably looking for a change made after 589093 (known good), but no later than 589100 (first known bad). CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/c228767123147cb184116a7e71dd837bfd56b062..c480691dbc893c156f0ee9880e1c46fa482a5766 Suspecting r589098 -> https://chromium-review.googlesource.com/1185300 author Kevin Bailey <krb@chromium.org> Thu Sep 06 03:57:18 2018 [omnibox] Accessibility announcements for un/focus tab switch button Commit c9aa3e02... initially landed in 71.0.3545.0
,
Jan 15
Note #c12 repeats findings in Issue 890203 , except on Mac instead of Windows. I created a dodgy revert of r589098 in https://chromium-review.googlesource.com/c/chromium/src/+/1410344 and the problem went away. (It's not a clean revert). un-reverting, the problem came back. Note the specific means used to switch input methods may cause the bug to happen or not. The exact repro steps I used on Mac were: - System Prefs -> Keyboard -> Input Sources -> Japanese (add it via the '+' button). - Ensure 'Show Input menu in menu bar' is ticked - Run Chrome, Switch to 'Hiragana' input via menu bar (this enables shortcuts to switch methods) - Focus omnibox, clear it - Press Ctrl+Shift+; to enable Romaji input (menu bar should show 'A') - Type 'bing.com', press tab - omnibox should switch to 'Search Bing' <-- (the bing.com keyword is present on a fresh profile) - Press Ctrl+Shift+J to enable Hiragana input (menu bar should show the hiragana a character) - Type "shi" Expected: a single, Japanese "shi" character Actual: a Latin "s" followed by the Japanese "hi" character. These steps work in a fresh install. Extensions or keyword setup are not required.
,
Jan 15
Happens on ChromeOS too. i.e. bing.com<tab><Ctrl+Space>shi will enter "ｓひ", not "し"
,
Jan 15
Hi Trent, Since I still can't duplicate it (on Linux where I can try changes), could you verify that only commenting out the change on omnibox_popup_model.cc#209,210 corrects the behavior? If so, I can work around it.
,
Jan 15
You're likely on a different master branch ref than me, but commenting out line 208 per https://chromium-review.googlesource.com/c/chromium/src/+/1412093 results in the steps of #c13 correctly typing a "し" character on Mac.
,
Jan 16
(6 days ago)
Correct, I was referring to the lines in my CL, the addition. Oh well, I'll just try my work-around and see how it goes.
,
Jan 17
(6 days ago)
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/33c72e13ece49c36938905cb6d87fbf15e9a0cfb commit 33c72e13ece49c36938905cb6d87fbf15e9a0cfb Author: Kevin Bailey <krb@chromium.org> Date: Thu Jan 17 02:24:13 2019 [omnibox] Condition accessibility call An added call is apparently triggering IME misbehavior. Condition the call to only when it is needed. Bug: 896962 Change-Id: I9bfb9aa702d5860f5274c78f9e8f0bb37109f685 Reviewed-on: https://chromium-review.googlesource.com/c/1413882 Reviewed-by: Justin Donnelly <jdonnelly@chromium.org> Commit-Queue: Kevin Bailey <krb@chromium.org> Cr-Commit-Position: refs/heads/master@{#623521} [modify] https://crrev.com/33c72e13ece49c36938905cb6d87fbf15e9a0cfb/components/omnibox/browser/omnibox_popup_model.cc
,
Today
(7 hours ago)
Confirmed the issue is resolved using the latest Dev 73.0.3679.0 with Microsoft Japanese IME and traditional Chinese new phonetic IME on Windows 7. |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by jdonnelly@chromium.org
, Oct 19Components: -UI UI>Browser>Omnibox