Flicker when use Chinese IME for the first character

[younky-yang]

When you input text using Chinese IME, the first char cause a reposition of the input bar shows on windows. This create a very bad experience when input text other then English.

[alexdima]

This is quite difficult to improve. The current strategy is the following:

• we use a hidden textarea for editor input
• when we received IME events from the textarea, there is no way to get from the DOM the current string being built until the string is finished.
• therefore, we reveal the textarea at precisely the right location in the editor such that it appears the editor is getting the input, when in fact it doesn't
• it is a cheap trick and we need to recheck if browsers have evolved or if the trick can be further improved.

[Tyriar]

@alexandrudima has there been any update on this since November?

[alexdima]

#5615 added improvements to CJK IME handling. Not sure if it improves this case too.

[younky-yang]

I tested with the latest release 1.1.1 on Mac, the behavior is same as before. Really hope this can be solved soon and provide the experience like it on Windows

Thanks for your great work

[alexdima]

@younky-yang With 1.2.0 we have merged in PR #5615. Would you mind trying it out

[younky-yang]

I have tried both 1.2.0 and 1.2.1, and the issue is not fixed yet. There is no issue on Windows, but I only have this one occurred on Mac. This is really annoying when type in Chinese in this great editor.

[younky-yang]

I attached the gif to explain the problem. No matter which IME i used, if it is chinese, the issue is always there.

[dgeibi]

I have the same problem on Linux.

[alexdima]

We are now always positioning the <textarea> we use for input with the primary cursor. This makes it that on the first use of IME input after a focus gain, the suggestion list is positioned correctly. Unfortunately, on the second use of IME input, the suggestion list displays in the top left corner of the page. Since I could not reproduce this in Chrome proper, I believe it is an Electron issue and I suggest we continue tracking this issue at electron/electron#9380

[rebornix]

Ref electron/electron#9380 (comment) , Right now, there are two cases that you won't run into the issue

1. Press any number before compositing Chinese characters
2. Have a visible webview. It means if you have Markdown Preview open on the side, then you don't run into the problem.

Markdown Preview is the golden workaround at this moment. >3 @mjbvz

[wangweixuan]

As we adopt Electron 1.7, the upstream issue is solved. Now the suggestion list no longer displays in the top left corner, but it is still located a bit higher than its intended position. I believe this is because we set the size of the textarea to 1x1, instead of the actual line height, which is used by the IME to determine the position of the suggestion list. So I think always setting the actual line height to the textarea can eventually solve the issue.

[younky-yang]

With the latest 1.16 release, it is better but still has problem. I hope that next version we can eventually solve the issue. This is the only annoying defect to me as use Code on Mac.

[bpasero]

Does this still happen with 1.26?

[wangweixuan]

@bpasero

Based on my test (latest Insiders, macOS, Chinese IME):

1. Composition box no longer goes to the top left.

The problem mentioned in the original issue no longer happens since we adopted Electron 1.7, which fixed the upstream bug.

2. Composition box overlaps the line content on certain occasions.

As I have pointed in an earlier comment #356 (comment), the problem is caused by wrong positioning of the textarea.

https://github.com/Microsoft/vscode/blob/4f162b7b6ece064e58664ad000e1001b707d7023/src/vs/editor/browser/controller/textAreaInput.ts#L147-L161

Currently we have the size of the textarea set to 1x1, and change it to the real font size on the compositionstart event (line 160 in the code above, which calls the handler in textAreaHandler.ts). But the IME calculates the position of the composition box before that event is triggered, so the box is positioned higher than expected, overlapping line content.

I have tested that the problem could be work-arounded with the following styles:

.monaco-editor .inputarea {
    font-size: 12px !important; /** your font size here **/
    width: auto !important;
    height: auto !important;
}

Open the inspector and copy it in should partially fix the problem. It forces the textarea to stay the real size all the time, which makes the textarea visible and produces an ugly background, so I think a better solution could be applied.

3. Composition box is placed to the right of the line content on certain occasions.

The cause of this problem is similar to the previous one. In line 157 of the code above, we clear the textarea so the composition box is placed at the cursor position. But the IME calculates the position of the composition box before that event is triggered, so the box is placed at a wrong position again. I tried to move the clearance to compositionend event, but that would bring back microsoft/monaco-editor#339.

[Alecyrus]

Work not properly in monaco-editor (Chrome 71)
.

I do not notice this weird Composition box now on most situations in vscode. Realy curious about how vscode to improve this ?

How to reproduce

Just use monaco-editor official example, and type anything use IME

[vscodebot]

This issue is being closed to keep the number of issues in our inbox on a manageable level, we are closing issues that are not going to be addressed in the foreseeable future: We look at the number of votes the issue has received and the number of duplicate issues filed. More details here. If you disagree and feel that this issue is crucial: We are happy to listen and to reconsider.

If you wonder what we are up to, please see our roadmap and issue reporting guidelines.

Thanks for your understanding and happy coding!

[sanxing-chen]

Version: 1.42.0-insider
Commit: 7c0095e
Date: 2019-12-20T07:55:38.353Z
Electron: 6.1.6
Chrome: 76.0.3809.146
Node.js: 12.4.0
V8: 7.6.303.31-electron.0
OS: Darwin x64 18.7.0

In my experience in the latest insider version, using the macOS build-in Chinese IME, the candidate box is usually in a usable position. At least, it doesn't overlap with the text I'm currently inputting. But It did shift to the right a bit from time to time, especially when using an extended screen, it will float to the other screen sometimes. So I suggest we can simply enforce the IME alway in the screen vscode is opened (if it's simple to fix).

[friskit-china]

Hi, is there any update? I am running Mac OS 10.15 Catalina with double screens, the candidate box often float to another screen.

[sanxing-chen]

Version: 1.42.0-insider
Commit: 7c0095e
Date: 2019-12-20T07:55:38.353Z
Electron: 6.1.6
Chrome: 76.0.3809.146
Node.js: 12.4.0
V8: 7.6.303.31-electron.0
OS: Darwin x64 18.7.0

In my experience in the latest insider version, using the macOS build-in Chinese IME, the candidate box is usually in a usable position. At least, it doesn't overlap with the text I'm currently inputting. But It did shift to the right a bit from time to time, especially when using an extended screen, it will float to the other screen sometimes. So I suggest we can simply enforce the IME alway in the screen vscode is opened (if it's simple to fix).

Hi @rebornix and @alexdima, will you consider reopening this issue since it seems to affect many people and haven't been touched (1.46.0-insider). I gave a potentially useful idea above, it would be great if you can give some comments. Thanks!