on Windows 10 (10586.494)

any IME can't use.
54.0.2817.0, win10 10.0.10586

Shu, can you take a look?

 Issue 634228  has been merged into this issue.

Repro'ed locally on my Windows 10.

I think bisect would help. How can I install the previous canary builds?

> How can I install the previous canary builds?

Hmm, I'm not familiar with Chromium development anymore.

yoichio@, kochi@: Can you help Shu to find the build/CL that introduced this regression?

Same problem occurred again on a different PC (MS Surface Pro 2 on Windows
10) when the canary updated to Version 54.0.2817.1.

Unsure which canary build the SP2 had prior to the update but now MS IME is
once again disabled.

Was there a major change over the canary builds in recent months? I am not
knowledgeable in CS but something in the coding over the recent update
definitely triggered the symptom.

Just FYI, here is the list of changes made between 54.0.2817.0..54.0.2819.0:
https://chromium.googlesource.com/chromium/src/+log/54.0.2817.0..54.0.2819.0?pretty=oneline&n=10000

Also there is the --pretty=fuller version:
https://chromium.googlesource.com/chromium/src/+log/54.0.2817.0..54.0.2819.0?pretty=fuller&n=10000

Oops, if this was already reproducible with 54.0.2817.0, then diffs between 54.0.2817.0 and 54.0.2819.0 are likely to be unrelated.

Maybe we can start from 54.0.2816.0..54.0.2817.0.
https://chromium.googlesource.com/chromium/src/+log/54.0.2816.0..54.0.2817.0?pretty=fuller&n=10000

Just to be clear, I don't (yet) say this started happening between 54.0.2816.0 and 54.0.2817.0. but according to the the Twitter search this seems to have started happening pretty recently.

https://twitter.com/search?f=tweets&vertical=default&q=chrome%20canary%20ime&src=typd

So far there were 3 people were explicitly tweeting that this is reproducible on 54.0.2817.0, while I could not see any other older build numbers that seemed to be related to this issue.

54.0.2819.0 still can't use.

+ekaramad@ working on OOPIF + textinput.
(but as far as I checked, there is no change by you in 54.0.2816-2817)

@shuchen: Could you please let us know if the narrow bisect is required for the bug? SO that we can provide the details accordingly.

Thank you.

I'm not shuchen@, but having bisect is definitely helpful here.

I don't have windows machines right now, so I can't run bisect-builds.py.

Also, can anyone provide information if IME does not work only on web pages,
or does not work on URL bar either?

It occurs on both URL bar and web pages.

tinydew4@ thanks for the input!

I don't think it is related to OOPIF specially given the URL bar problem. My last CL on IME OOPIF (content/) was before this bisect range.

rnimmagadda@, it would be great if you can help to bisect and find the root cause cl.

Thanks!

====================================

Good Build:

54.0.2815.0   Base Position: 408889


Bad Build:

54.0.2820.0   Base Position: 409955

=====================================

Able to repro this issue on Windows 10 [Pro] for the Google Chrome Canary Version - 54.0.2820.0

This is a regression issue broken in M54, below mentioned is the bisect info:

CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/7db633ed3af213c5220d188fb9caf4b1e1973692..df585142df9fd58299ef02b64da3381d8b733cb8

Suspecting Below:

=======================================================

Commit: 1909e832326794bd74265f93d32407aeeb131253		

Review URL: https://codereview.chromium.org/2198933003

——————————————————————————————————————————————————————

Commit: 73c4ead9db3aad5e06d354c3091b6749a32e77a4		

Review URL: https://codereview.chromium.org/2199773002

=======================================================

@creis / eseckler: Could you please look into the issue, and if it has nothing to do with your changes and if possible please do assign it to the concerned owner.

Thank you.

Note: Issue is on Windows OS only.

https://codereview.chromium.org/2199773002 only affects headless builds, so should not be related.

I'm OOO until Monday.  ekaramad@, can you try reverting my CL locally to see if it fixes the problem?  I'd be surprised if it could affect IME.

creis@: I will take a look.

Could someone please elaborate on the repro steps? I am not quite sure Korean/English switch? I assume this is a Windows 10 only bug since IME for on Widows 7 seems to be working just fine.

I could see this on Windows 10 Chrome Canary. So it is Windows 10 only.

Not repro:
 - Windows 7 SP1 / Chrome Canary 54.0.2820.0 (64-bit) / built-in MS-IME Japanese

Repro:
 - Windows 10 Version 1511 (OS Build 10586.494) / Chrome Canary 54.0.2820.0 (64-bit) / build-in MS-IME Japanese 

ekaramad@: Here is a repro step:
 1. Add a language that requires IMEs (e.g. Japanese, Korean, Chinese, ...) at control panel.
 2. Launch Chrome
 3. Focus into Omnibox

Actual:
 There is a circled cross icon on the notification area next to the IME icon. This basically means that IME is disabled in the focused field. See the attached crbug634192_canary.png.

Expected:
 There is no circled cross icon on the notification area next to the IME icon. See crbug634192_stable.png for example, which was taken with 51.0.2704.106.

Deleted: crbug634192_canary.png 4.7 KB

	crbug634192_canary.png 4.7 KB View Download

Deleted: crbug634192_stable.png 4.3 KB

	crbug634192_stable.png 4.3 KB View Download

+jbauman@, can you please confirm whether the cl https://codereview.chromium.org/1811913007 might be the cause of this issue?

Thanks!

FYI. I'm OOO and PEK office is moving so I don't have a dev machine for now to investigate. So I'm using my Macbook to guess around the suspicious CLs.

I just tried a build with https://codereview.chromium.org/1811913007 + 54.0.2816.0 and it doesn't repro the problem, so I don't think it's my patch.

https://chromium.googlesource.com/chromium/src/+/df585142df9fd58299ef02b64da3381d8b733cb8 seems like the cause. Adding HKCU\SOFTWARE\Google\Chrome\BrowserSboxFinch fixes the issue (until chrome is restarted and the key is deleted).

jbauman@, thanks for your investigation.

pennymac@, can you please take a look? Thanks.

Add HKCU\SOFTWARE\Google\Chrome\BrowserSboxFinch and solved. Thanks.

each time I must create the key before run it.
the key is deleted after execution.

jschuh@, pennymac@: Is there any chance that this is prioritized?  Currently IME is completely unusable on Windows 10, possibly because our sandbox experiments.  I personally feel this is dev release blocker...

HKEY_CURRENT_USER\SOFTWARE\Google\Chrome\BrowserSboxFinch

or

HKEY_CURRENT_USER\SOFTWARE\Google\Chrome SxS\BrowserSboxFinch

or

both?

I use this code temporarily.

@reg add "HKEY_CURRENT_USER\Software\Google\Chrome\BrowserSboxFinch" /ve /f
@start /D "%userprofile%\AppData\Local\Google\Chrome SxS\Application" chrome.exe --enable-accelerated-compositing --enable-gpu-rendering --enable-video-layering --enable-webgl --enable-accelerated-2d-canvas --enable-fastback

Hello,

Thanks for the feedback tinydew4!

This is definitely the new EXTENSION_POINT_DISABLE mitigation.  It blocks legacy forms of hooking in Windows (third party dll injection into the Chrome processes).
Ref: https://bugs.chromium.org/p/chromium/issues/detail?id=557798  

As of right now, I've reverted the "on switch".  The next canary will no build (tomorrow?) will no longer have it turned on.  https://codereview.chromium.org/2227453002/  
At least until I can do some in-depth analysis of IMEs used, and how close they are to not using these legacy injection techniques.


Thanks to everyone that spent time triaging this ticket!

 Issue 635210  has been merged into this issue.

Re https://codereview.chromium.org/2227453002/
> What percentage of Chrome IMEs are actually still using legacy hooking techniques to inject DLLs into our processes?

I'm afraid it's actually 100%, simply because Chromium still relies on legacy IME API called IMM32 to communicate with IMEs.  The issue here is probably not that IMEs are legacy but that Chromium still uses legacy IME APIs.  The bridge layer called Cicero Unaware Application Support (CUAS) depends heavily on message hook last I checked.

Just FYI, Chromium used to use new IME API called Text Services Framework (TSF) for Metro mode, but the code was already removed in https://codereview.chromium.org/149073009.  Although there is no technical blocker for Chromium to support TSF again, it probably takes more than half a year with lots of non-trivial works.  Please let me and shuchen@ know if this is going to be a blocker of Issue 557798.

 Issue 635291  has been merged into this issue.

ALL IME CAN'T INPUT on EXTENSION_POINT_DISABLE?

(Aside: this ticket applied to >= Windows 8.)

FYI: I've re-landed the security mitigation for child processes only (557798).  It is now out on 54.0.2824.0 and up.

This passed my manual IME tests on a win10 machine.  tinydew4@, would you mind verifying that IME works on >= 54.0.2824.0 (latest canary)?
Once verified, I will close down this ticket.


Yohei and Shu, are there no automated tests on the waterfall for chromium IME support?  Also, we should follow up on a separate/new ticket to track changing the IME internals to not use legacy hooking techniques - it will definitely block 557798 for the browser process.

Thanks!

54.0.2824.0 resolved the IME disabled issue.

Thank you guys.

pennymac@ It works fine. thanks.

54.0.2824.0 canary (64-bit)