Japanese IME input mode switched back to Direct Input after pressing Enter key

[rabianr]

Windows Terminal version

1.14.1451.0

Windows build number

10.0.19044.1766

Other Software

No response

Steps to reproduce

• Turn on Hiragana input mode
• Type something then press Enter to convert to japanese

Expected Behavior

The input mode should not switch back to Direct Input

Actual Behavior

The input mode switched to Direct Input automatically after conversion

[driver1998]

Might be related: #12731

[driver1998]

If we can't have a smarter way to detect when should we use compose mode and when should we use direct input, I would like to have an option to disable this behavior. Since I already installed a separate English (US) language along side Chinese (Simplified, MS Pinyin) so that I can turn off IME for good if I don't need it.

[driver1998]

At least MS Pinyin handles it this way with conhost:

On first start of conhost, uses direct input by default.
If user enables compose mode with Shift, do not automatically switch back to direct mode.

[tadashi-aikawa]

I have encountered this issue, and it never occurred in previous versions.

When I write a git commit message mixed in English(alphabet) and Japanese, I often commit unintentional messages. (and have to amend commit again...)

Best regards.

[rabianr]

Might be related: #12731

It's indeed related as the problem occurred after upgrading to v1.14.1432.

Hope that there is a way to disable this behavior, because I tend to press enter key to end IME composition.
Automatically switch back to direct mode each time make it hard to input Japanese text in the terminal.

[BingFengHung]

I also have the same problem.

When I type Chinese, then I press enter it jumps to English IME.
But I am not done with my Chinese typing.

[yuru7]

This problem does not occur with Google Japanese Input.
However, there is a bug that it automatically switches to "HankakuEisu" mode when starting Windows Terminal.

[shinsaka]

I'm having the same problem with MS-IME on Windows Terminal version 1.14.1963.0.
I hope it fixes. 🙏

[YossyHal]

When the Microsoft IME version was lowered, this event no longer occurred.

[ironsand]

When the Microsoft IME version was lowered, this event no longer occurred.

It didn't work for me. Does someone know other work-arounds?

[yuru7]

If finalize with Ctrl-m instead of Enter, the IME will not turn off. But it is incredibly annoying method 😅

You could write following AutoHotKey script based on the hack.

#IfWinActive, ahk_exe WindowsTerminal.exe
  Enter::Send, ^{m}
#If

[megane42]

I'm running into the same issue.

In my environment, I can avoid the issue by waiting 0.5 - 1.0 seconds before pushing enter. Hope this helps some debugging.

[hqf00342]

I also have the same problem.
In my case, the workaround mentioned by @YossyHal works fine. (ver1.14.1963.0, on Windows11 22000.795)

When the Microsoft IME version was lowered, this event no longer occurred.

ty.

[zadjii-msft]

I wonder if there's a way to only request AlphanumericHalfWidth the very first time the IME opens for a pane, and then just continue using the previously used mode for subsequent invocations.

@YanceyChiew as an FYI. I'm not as familiar with the intricacies of the IME APIs, so you might have some better ideas here.

Link for future me: #13028

[YanceyChiew]

I wonder if there's a way to only request AlphanumericHalfWidth the very first time the IME opens for a pane, and then just continue using the previously used mode for subsequent invocations.

In short, yes, there is.

This is the default behavior for Chinese input, so I thought there was no need for additional processing, but I didn't expect it to cause trouble for Japanese input method users.

---

The root of the problem lies in these few lines of code:

    void TSFInputControl::ClearBuffer()
    {
        if (!_inputBuffer.empty())
        {
            TextBlock().Text(L"");
            const auto bufLen = ::base::ClampedNumeric<int32_t>(_inputBuffer.length());
            _inputBuffer.clear();
            _editContext.NotifyFocusLeave();
            _editContext.NotifyTextChanged({ 0, bufLen }, 0, { 0, 0 });
            _editContext.NotifyFocusEnter();
            _activeTextStart = 0;
            _inComposition = false;
        }
    }

It can be seen that this code will not perform any effective operation when _inputBuffer.empty(), which is consistent with the performance of the Japanese input method that does not exit composition mode when press Enter directly with empty command line.

Maybe it is because the Microsoft Japanese input method is in the English (direct) input mode by default, and it's handling of lost input focus is also different from the Chinese input method, after each call to _editContext.NotifyFocusLeave(), it will exit from the composition input mode to the direct input mode.

Incidentally, in another issue(#1304), someone wanted such a feature, but I found it difficult to implement cleanly.

(ps. When using the old Japanese input method, it will exit to direct input mode when pressing enter only when there are no characters in the input buffer of composition mode, so only newlines will cause composition mode to exit uncontrollably.)

---

The easiest solution I can think of is to modify the _editContext.InputScope back to CoreTextInputScope::Text as soon as the input method gets focus for the first time. By testing in another example project, I found that it works fine with both Chinese and Japanese input methods.
The key is that the timing of modification should be between the first and second calls to _editContext.NotifyFocusEnter().

But in this project, I haven't found a suitable place to insert that line of code yet. It can also be inserted in the code block quoted above, TermControl will call it when Esc or Enter is pressed, inserting code anywhere before _editContext.NotifyFocusLeave() will take effect in time, but that looks a bit dirty doing pointless operations multiple times.

[hqf00342]

It seems you are right.
I removed the changes in PR #13028 from the current HEAD(7976e48) source, compiled it, and confirmed that it works fine with the current version of Japanese MS-IME.

I changed the line at at src/cascadia/TerminalControl/TSFInputControl.cpp:43

     _editContext.InputScope(CoreTextInputScope::AlphanumericHalfWidth);

to

     _editContext.InputScope(CoreTextInputScope::Text);

I agree with what you tried to do with your PR #13028,
we would like to find a good way to make both Japanese and Chinese users happy.

P.S.
However, there may be other causes as well.
It seems that this issue only occurs with the current version of Japanese MS-IME, not with Google-Input or MS-IME(previous ver). I also tried ATOK2022, a typical Japanese IME, but it didn't occur this issue.

[YanceyChiew]

However, there may be other causes as well.
It seems that this issue only occurs with the current version of Japanese MS-IME, not with Google-Input or MS-IME(previous ver). I also tried ATOK2022, a typical Japanese IME, but it didn't occur this issue.

This may be because InputScope is not implemented by the two non-Microsoft input methods mentioned above, its enum values ​​are simply ignored. And in my test, the old version of Microsoft Japanese input method will also be affected when wrapping.

[YanceyChiew]

So, the question now is, use the simple solution to change the _editContext.InputScope back to CoreTextInputScope::Text as soon as the TSFInputControl is connected to the input method for the first time, or add a setting to the _editContext.InputScope as originally envisaged if it doesn't satisfy all users?

Both methods can solve the current problem, If we choose the former, since it cannot be assumed that the window is initialized with input focus, the code may have to be inserted before _editContext.NotifyFocusLeave(), making it itself or the code that determines whether it needs to be executed repeatedly.

Insert code here and it will be repeated every time the window regains focus, not every time enter is pressed.

    void TSFInputControl::NotifyFocusEnter()
    {
        if (_editContext != nullptr)
        {
            _editContext.NotifyFocusEnter();
            _focused = true;
           // CODE INSERT HERE
           // _editContext.InputScope(CoreTextInputScope::Text);
        }
    }

If we choose the latter, do we need to expose the option to the settings page in the gui, and have the default value determined by the user's system locale?

[hqf00342]

I think we should wait a while for other reports.
cf. @ironsand says that even using an older version of the IME did not work around this issue.

I'd like to vote for "add a setting". And "Set default values determined by the user's system locale" is a good idea. With this, most people will not need to change this setting, so it seems to me that there is no problem even if editing the json is the only way to change this setting. (of course, it would be nice to have a gui)

[lhecker]

I believe the easiest fix is to remove the calls to NotifyFocusLeave() and NotifyFocusEnter() inside TSFInputControl::ClearBuffer(). But I'm currently waiting to see whether I can fix the general behavior of the input first (#11479).

[ghost]

🎉This issue was addressed in #13678, which has now been successfully released as Windows Terminal Preview v1.15.228.:tada:

Handy links:

• Release Notes
• Store Download

[rabianr]

I'm sorry for bringing this up again.
Thanks to the commit #13678, the original issue is fixed in the latest version.
But recently, I've found that the new behavior is not very desirable. At least for me.
For example, when I'm in the middle of editing something in Hiragara mode then switch to a different application or make the Terminal lose focus. Then when the Terminal get focus again, the IME's input mode will be switched to Half-width alphanumeric.
It's not a bug, but kind of inconvenience. So may I request a setting to disable the new behavior?

v1.13.10983.0

v1.15.2282.0

I don't have other CJK languages installed, so it might happen with the Japanese MS IME only.

Also, I believe that the new behavior is causing alt + shift to not retaining the last used input mode as mentioned in #13681.

v1.13.10983.0

v1.15.2282.0