Why has the conflict between Japanese IMEs and single-key application shortcuts persisted for so long? (Not a Mozc-specific bug report)

[synya55skyway-cpu]

This is not a Mozc bug report. I am posting here because I would like to hear from people familiar with IME implementation about a broader design issue related to Japanese text input systems.

Background

I have been looking into the interaction between Japanese IMEs and application-level keyboard handling on Windows.

What prompted my interest was the behavior seen in applications such as Photoshop, Illustrator, and Premiere Pro: when the Japanese IME is ON, single-key shortcuts such as V, M, or A may not reach the application and are instead handled by the IME as text input.

When the user is actively entering text, it is natural for the IME to receive those keystrokes. However, the same keys may also be application commands when the user is not entering text.

This makes me think that distinguishing between text input and application commands cannot be determined simply by whether the IME is ON or OFF.

It may also depend on whether the user is currently entering text, the current IME state, which UI element has focus, whether the key represents text or a command in that application, and the sequence of input and operations immediately beforehand.

Question

For those familiar with IME or Japanese input-system development:

Why do you think this kind of conflict between input modes and application commands has persisted for so many years?

At the moment, I suspect several factors may be involved. The IME may not be able to fully understand the application's current state, while the application may not be able to fully understand or control the IME state. Responsibility is also divided among the OS, IME, and application. In addition, automatic detection or switching may itself introduce incorrect behavior, while backward compatibility with existing applications must also be preserved.

Before considering specific solutions, I would first like to understand why this problem has remained structurally difficult from the perspective of people who actually develop input systems.

I realize this is not a Mozc-specific question, but I would greatly appreciate any thoughts on the technical or historical reasons behind this issue, as well as any references or materials you would recommend.

[yukawa]

Thanks for the interesting question. The short answer is that the mechanism to make single-key shortcuts coexist with an active IME has existed in Windows for decades, and the symptom itself tells us what these Adobe apps are not doing: a Windows application can disassociate its input context whenever its internal focus is not on a text field, and single-key shortcuts then pass through to the application even with the IME ON. The fact that V/M/A get eaten means that this disassociation is not happening on the application side.

A likely reason is architectural: Adobe's desktop apps are built on a custom widget toolkit, where the transition from "text field" to "canvas" happens inside the toolkit — largely invisible at the level where the IME association is managed. Note that Japanese input does work in a text layer, so these apps are IME-aware; they just don't tell the IME when focus leaves text.

I realize this is not a Mozc-specific question, but I would greatly appreciate any thoughts on the technical or historical reasons behind this issue, as well as any references or materials you would recommend.

My suggestions would be:

• Use a debugger or debugging tools to identify whether Adobe apps are still using the legacy IMM32 APIs or the current mainstream Text Services Framework (TSF) APIs.
• Look into the API documentation and sample applications to confirm that there are ways to make single-key shortcuts coexist with an active IME in both API families — e.g. ImmAssociateContextEx on the IMM32 side, and ITfThreadMgr::AssociateFocus / focusing an empty document manager on the TSF side. These are what Adobe apps are not doing.

[synya55skyway-cpu]

Thank you very much for the detailed explanation. Following your suggestion, I tried to investigate this further with Accessibility Insights, Spy++, and WinDbg.

I should mention that I am not an IT/software professional, so I relied heavily on AI assistance to understand WinDbg, IMM32/TSF, and the traces. If my interpretation is incorrect, I would greatly appreciate any correction.

In Illustrator 2025 on Windows, both text editing and normal canvas operation remained in the same OS_ViewContainer and the same HWND (0x00060ACC).

With WinDbg, I confirmed that Illustrator does call ImmAssociateContext, including at least one call with a NULL HIMC. However, during controlled transitions between text editing and normal canvas/tool operation, I did not observe ImmAssociateContext or ImmAssociateContextEx being called.

I then monitored TSF. AssociateFocus activity was visible when Illustrator itself gained or lost Windows focus, including activity for the same OS_ViewContainer HWND. I also monitored SetFocus and _SetFocus.

In a timed test switching between the selection tool, text tool, editing existing text, and leaving text editing, I did not observe corresponding TSF focus changes during those internal Illustrator transitions.

So, unless I am misunderstanding the traces, this seems consistent with your explanation: Illustrator supports the Windows IME/TSF mechanisms, but the internal transition between “text editing” and “canvas operation” does not appear to be reflected as a corresponding Windows input-context or TSF focus transition.

Does this seem like a reasonable interpretation of these observations?

Thank you again for pointing me in the right direction.

[yukawa]

So, unless I am misunderstanding the traces, this seems consistent with your explanation: Illustrator supports the Windows IME/TSF mechanisms, but the internal transition between “text editing” and “canvas operation” does not appear to be reflected as a corresponding Windows input-context or TSF focus transition.

Does this seem like a reasonable interpretation of these observations?

So far, your observation and interpretation sound reasonable. If you would like to dig further into the details with AI agents, ask AI agents to use Microsoft's official debug symbols. You may observe certain TSF callbacks are done by CUAS (Cicero Unaware Application Support) rather than the target application itself.

[synya55skyway-cpu]

Thank you very much for the detailed explanation.

It is very helpful to know that my observations and interpretation so far appear reasonable.

Your point about CUAS (Cicero Unaware Application Support) is especially important. I had been looking at the observed TSF behavior as if it were necessarily being initiated by Illustrator itself, but I now understand that some of those callbacks may instead be generated by the Windows compatibility layer.

I will try to investigate this further using Microsoft’s official debugging symbols, as you suggested, and see whether I can distinguish calls originating from the target application from those originating from CUAS.

Thank you again for pointing me in the right direction.