Rachel, can you help us find an owner for this issue ?
It's a long standing, low feedback issue but I feel it still needs to be addressed given it worked earlier and on other browsers

I read the reports, and it sounds like the issue is that macOS predictive input for Chinese works in the chrome omnibox but not in text fields in the content area. 
+ some Mac UI engineers

Hello guys I'm the original reporter on the Google Chrome forum. Any updates on this bug? AFAIK (four months since upgrading to MacOS Sierra and counting..) this is quite a serious and widely affected bug.

1. Besides the not working predictive input all the time, it will also trigger app crash sometimes when apps/input methods are quickly switched and user types immediately.

2. The same bug can be found in some other common apps, e.g. Slack, WhatsApp, etc. Same behavior (app crash included). 

Putting into the blink triage queue.

I observed different buggy behavior on my Mac with M57 and M59:

1. Switch input method to Cangjie for Traditional Chinese.
2. Type anything in the webpage. Predictive suggestions appear, but are irrelevant to the previously typed text.
3. Type anything in the omnibox. Predictive suggestions appear and are relevant.

I haven't observed any crashed mentioned in #3. Guess that's a different issue. You may find out the crash in about:crashes and click "Provide additional details" to file another bug report.

Deleted: Screen Shot 2017-04-27 at 11.34.35 AM.png 78.3 KB

	Screen Shot 2017-04-27 at 11.34.35 AM.png 78.3 KB View Download

Deleted: Screen Shot 2017-04-27 at 11.34.15 AM.png 160 KB

	Screen Shot 2017-04-27 at 11.34.15 AM.png 160 KB View Download

ekaramad@, could you take a look? Since, you worked InputMethodMacTest in
"render_widget_host_view_mac_unittest.mm"

It seems Blink failed to pass typed text information to Mac IME.

Remove: Blink>Editing>IME, since it covers IME API between content and Blink.

Sure. It does not seem related to my changes but I will take a look.

comment #5 xiaochengh@ or comment #3 foxan.ng@: 
Could you please help me repro the bug? I cannot get different behaviors from steps 2 and 3 posted in comment #5. 
I am pressing 'a' and seem to get the same suggestions for the composition string regardless of where the input is. I have attached a video for testing this in Chrome omnibox, an html page, and TextEdit.

OS： macOSSierra
Chrome: 58.0.3029.81 and 60.0.3082.0.
Input: Cangjie

Thanks!

Deleted: cangjie_ime_test.mov 3.1 MB

cangjie_ime_test.mov 3.1 MB Download

Hi comment #8 ekaramad@:

In order to type the Chinese character you need to press 1 to 8 to pick the character, or press space for current selection. The predictive completions in this discussion is the pop-up suggestions after choosing the character. (combining with the character typed we can form a word or phrase in Chinese)

Attached please find the video I reproduced the bug with the same environment as yours.

FYI this bug also happens with the SuCheng IME.

Thanks!

Deleted: cangjie_ime_repro.mov 672 KB

cangjie_ime_repro.mov 672 KB Download

comment #10: Thanks. I can see the difference now. I will take a look or try to find someone who might be more familiar with the issue. I will update the bug soon.

I did a bisect and I guess this is the range regression might have occured:
You are probably looking for a change made after 350169 (known good), but no later than 350176 (first known bad).
NOTE: There is a Blink roll in the range, you might also want to do a Blink bisect.
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/0b119f3392d6c6169bbb792347a04f34ce649156..8fb2e97817052a14982b410cae0da2e690781d0e

In versions before this the issue is flaky but more or less the correct behavior in the sense of comment #10 is observed.

Now based on the bisect my suspicion is this CL:
https://chromium.googlesource.com/chromium/src/+/7e0fac6e1d8c79e7658a94e96a3f0246dc541d82
which removes the sync behavior from two IME related IPCs. The CL specifically mentions a trade off between performance and correct behavior which I suppose might be the buggy behavior here.

cc-ing shuchen@ for some comments. Meanwhile I will try and see if the two IPCs could be locally reverted to verify that the sync->async caused this issue.

Chrome just crashed again while switching input method and then typing right away.. 

Part of the crash log:

Process:               Google Chrome [526]
Path:                  /Applications/Google Chrome.app/Contents/MacOS/Google Chrome
Identifier:            com.google.Chrome
Version:               58.0.3029.96 (3029.96)
Code Type:             X86-64 (Native)
Parent Process:        ??? [1]
Responsible:           Google Chrome [526]
User ID:               501

Date/Time:             2017-05-11 18:37:22.897 +0800
OS Version:            Mac OS X 10.12.5 (16F60a)
Report Version:        12

System Integrity Protection: enabled

Crashed Thread:        0  CrBrowserMain  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_BAD_INSTRUCTION (SIGILL)
Exception Codes:       0x0000000000000001, 0x0000000000000000

Application Specific Information:
Crashing on exception: Unable to activate constraint with anchors <NSLayoutXAxisAnchor:0x6000054614c0 "NSRemoteView:0x618000b37520.leading"> and <NSLayoutXAxisAnchor:0x600002c62040 "_NSCandidateBarFunctionRowButton:0x7fa3b477c640.leading"> because they have no common ancestor.  Does the constraint or its anchors reference items in different view hierarchies?  That's illegal.

Application Specific Backtrace 1:
0   CoreFoundation                      0x00007fff826ca2cb __exceptionPreprocess + 171
1   Google Chrome Framework             0x000000010885b6bb ChromeMain + 23438347
2   libobjc.A.dylib                     0x00007fff974d348d objc_exception_throw + 48
3   CoreFoundation                      0x00007fff82748c3d +[NSException raise:format:] + 205
4   AppKit                              0x00007fff80813587 -[NSCandidateListViewController _updateCollapsingStateConstraint] + 179
5   AppKit                              0x00007fff808136b8 -[NSCandidateListViewController updateViewConstraints] + 59
6   AppKit                              0x00007fff801a0ab6 -[NSView _updateConstraintsForSubtreeIfNeededCollectingViewsWithInvalidBaselines:] + 828
...

Thanks for the update. It might also help to add a sample crash ID here (from chrome://crashes).

Crash ID of the above crash: c3f84230d0000000

Thanks. The issues you are experiencing might be two different bugs (suggestions not showing up vs crash) or might be the same. I am cc-ing more people who might know more about them.

cc-ing yabinh@ for possible help with this bug.

yabinh@: Could the repro in comment #13 be helpful with issue 671595?

Sorry I have left Chrome team. cc-ing aelias@ for possible help.

Issue 671595  was caused by https://codereview.chromium.org/2493703002, which has been reverted, so I think issue 671595 is irrelevant to this issue.

That crash seems like it should be filed as a separate bug, and I also don't see any evidence implicating my or yabinh@'s changes in any of the Chinese IME bugs here.

OK, on a second look, although the stack looks different, I understand the connection is that the exception message in http://crbug.com/671595#c3 is the same as the one reported in this bug in #13.  So it may well be a local repro of it.  Anyway, let's follow up on the crash in http://crbug.com/671595 and keep this bug focused on the predictive text problem, then.

aelias@: Agreed (main reason I brought up issue 671595 was the repro steps posted here).

As for the predictive issue waiting on shuchen@'s comment and also local verification by myself (that 'somehow' reverting the CL in comment #12 might fix this).

The CL https://codereview.chromium.org/1327743002 was dealing with composition/selection bounds and retrieving text from range.

I'm not sure how predictive suggestion works, but guessing the change in attributedSubstringForProposedRange might be related.

ekaramad@, looking forward to your local verification results. Thanks!

comment #23: Actually reverting the patch looks nontrivial. But I tried something by caching the history of inserted text ("input.value") and trying to retrieve the proposed range from it and it kind sparked something related to word predictions. So my guess is that the call to 'attributedSubstringForProposedRange' does not return the right text which is currently inside the <input> behind the caret. If that is the issue we should be able to somehow resolve it given the many IME related state we are tracking including composition rand text selection.

Anyhow, I did not find a straightforward fix for this but I will keep investigating this week.

I'm still experiencing this issue on Mac OS Sierra 10.12.6. Is there any progress to fix it?

Apologies for the delayed response. Unfortunately I have not been able to make any progress on this since last year and I don't think I will be in near future (given that I don't work on IME anymore). Would anyone be able to pick this one up?

Hello hi, may I just ask if this has been fixed? Or is it planned to fix this at all?

Mac triage: marking for IME team triage.

Over to OWNER of third_party/blink/renderer/core/editing/OWNERS

This is caused outside of Blink and Blink>Editing doesn't know platform specific
IME.

We aren't likely to work on this soon. Marking for Q3 re-triage.

The NextAction date has arrived: 2018-09-01

tapted@, can you help with this? you know things about IME :)

I switched my input method to Cangjie and I don't think I can reproduce this. The completion results seem relevant and are consistent with Safari's address bar.
Tested:
 - Chrome Version 70.0.3534.4
 - macOS 10.13.6

See attached.

However, not that I am not a Chinese IME user, so it's possible I'm missing something.

Please comment/reopen if you are still seeing this, and let us know the Chrome and macOS version, and expected results.

Deleted: omnibox-views.png 30.3 KB

	omnibox-views.png 30.3 KB View Download

Deleted: textarea-blink.png 57.6 KB

	textarea-blink.png 57.6 KB View Download

Deleted: Safari.png 35.1 KB

	Safari.png 35.1 KB View Download

Hi tapted@, please check comment 10 in this chain where I've included a movie clip to reproduce the issue. (https://bugs.chromium.org/p/chromium/issues/detail?id=710101#c10)

Let me explain more to non-Chinese users. In Cangjie, each Chinese character is deconstructed and represented by a set of 26 basic shapes. (So that we can fit it on the keyboard) Each Chinese character is encoded from min. 1 to max. 5 keystrokes of the 26 basic shapes.

I think it may be causing confusion because there are actually two set of predictive completions here.

The first is the prediction (auto-completion) of the current Chinese character you're typing. For example, "時" (which is "agdi", i.e. "日土木戈") When you type "ag" (日土), it will return a list of Chinese characters which all start with "ag". This part works fine.

The second type of prediction, where the bug is, is word/vocabulary association. In Chinese, characters are grouped together to form words/vocabularies.
Just take "日" (a) as an example. After choosing the character "日" (either by "a" + space, or "a" then select 1), there will be a list of associated words (on non-affected applications, say Safari), which is "1本 2前 3子 4本人 5圓 6文 7後 8常". They all form vocabularies with the character "日", e.g. 日本 = Japan, 日前 = earlier, 日子 = day, 日本人 = Japanese, etc.
This is where the bug lies. The word/vocabulary association is gone. It returns a default list of words "1我 2這 3你 4但 5在 6他 7有 8也 9一" no matter what character you have typed before. This means a Cangjie-IME user (and also Quick, another IME with very similar methodology) has to type character by character, without the help of word/vocabulary association.

I swear that this bug has existed since I reported it almost two years ago and I'm facing it every single day when using Chrome on my Macbook. It's been there since Sierra, High Sierra and now I'm using Majove beta, still here. :(

It can also be easily reproduced by many applications using Electron, I've just tried a few ones: WhatsApp, Slack, Atom, nteract. All reproducible. It just shows how inconvenient it is and it's wildly affecting a lot of applications.

Please also check if this helps investigate the problem. https://bugs.chromium.org/p/chromium/issues/detail?id=671595#c22

Please let me know if it's still unclear or I can shoot a full video to explain it as clear as I can.

Hi tapted,

You are trying the auto completion of current character, which is not affected by this bug. This bug only affects next character prediction.

Let me describe the different between these two with the example of English IME.


In English IME, such as the gBoard on iPhone, we have current word completion and next word prediction.

When you entered two characters, such as  "g" and "o". the IME will try to auto complete the current word for you, it may show suggestions like "go", "google", "gold", etc.

Once you select the current word from the auto completion list, then the IME will try to predict the next word you want to enter. e.g. if you selected "google", then the IME may suggest you to enter "mail", "search", "calendar", etc. as the next word.


In Chinese IME, we don't have autocompletion and prediction in word level. We have these in character level instead. It is because each Chinese character is composited from numbers of English, e.g. 日 = a, 是 = aymo. When you enter "a", the auto completion will suggest "日", "曰", "是" as you post, because they are all started with character a. However, once you pick a word from the auto completion list, the Chinese IME should try to predict the next character, however, the prediction in Chrome are always the same, no matter what is the current word.

Please take a look on the video post in comment 10 for the detail.

By the way, the bug should be related to improper implementation of -attributedSubstringForProposedRange:actualRange:, as shuchen suggested at comment 23. 

BTW, another open sourced Google project, Xi editor, has the same issue.

Kit

Ah, ok I can repro that.

Steps:
 1. Enable Canjie input method
 2. Press "a<space>13" in a text field

Expected:
 日本🇯🇵

Actual:
 日我你


The interesting part is that this works in a toolkit-views text field (i.e. Omnibox as not become broken since it is no longer an NSTextField in m69).

That is,

The NSTextInputClient implementation in UI works (i.e. https://cs.chromium.org/chromium/src/ui/views/cocoa/bridged_content_view.mm?q=bridged_content_view.mm&sq=package:chromium&dr&l=1363)

but the NSTextInputClient implementation used for Blink does not work (i.e. vhttps://cs.chromium.org/chromium/src/content/browser/renderer_host/render_widget_host_view_cocoa.mm?type=cs&q=NSTextInputClient+implementation&sq=package:chromium&g=0&l=1447)

https://cs.chromium.org/chromium/src/content/browser/renderer_host/render_widget_host_view_cocoa.mm?type=cs&q=NSTextInputClient+implementation&sq=package:chromium&g=0&l=1447

Elly - I'm gonna bounce this back into triage (sorry!). But I think since this bug is comparatively non-urgent, not a regression, and hasn't really got any overlap with MacViews, it is a good opportunity for someone on the Mac team to learn about IME. I'm happy to review code, but we need someone else familiar with this stuff.

However, note I'm not really familiar with renderer IME plumbing - just bridged_content_view (and NSTextInputClient, which they both use). But since this bug _doesn't_ repro in MacViews, there's already a NSTextInputClient with the right plumbing :)

I did some tracing for this issue in https://chromium-review.googlesource.com/c/chromium/src/+/1206053 (but didn't really make progress on a fix) and I put together an "IME Recorder" to help write tests for another,  Issue 883952  - that's in https://chromium-review.googlesource.com/c/chromium/src/+/1239955 .

Any progress on this? This is a very important feature for Chinese users and not having the predictive completion makes work very inconvenient. I hope someone can resolve this soon.

Same here, would really appreciate someone is working on the fix, especially this issue has been around for such a long time. Thanks.