[yukawa]

Description

This commit aims to make use of IS_PRIVATE/IBUS_INPUT_HINT_PRIVATE signals in TSF/IBus by dynamically adjusting the learning level. To do so, a new Context.no_personalized_learning boolean field is introduced. The new field is interpreted as temporarily raising the effective Config::history_learning_level to READ_ONLY, so all the existing learning-suppression code paths are reused as-is.

The reason why this commit ended up introducing a new field in Context rather than reusing Request.is_incognito_mode like Mozc for Android is a bit ironic. Here is the historical context:

Mozc has supported its own "secret mode" concept long before it started supporting the Android Client. Its "secret mode" not only disables personalized learning but also disables personalized features such as user dictionary and history-based suggestions. On the other hand, IME_FLAG_NO_PERSONALIZED_LEARNING in Android IME API does not require the IME to disable all the personalized features. Its only request for the IME is to disable personalized learning, which is what I deliberately intended when designing the API (aosp-mirror/platform_frameworks_base@5959af1). The API was designed to keep Android API vendor-neutral and independent of app-specific concepts like "incognito" mode, which could have been changed at any time.

When the Chrome for Android team started using it in its "Incognito" mode (chromium/chromium@5c08787), Mozc for Android mapped IME_FLAG_NO_PERSONALIZED_LEARNING to its own "secret mode". The same behavior has also been inherited by Gboard.

Now that similar signals are available in TSF/IBus, the assumption here is that disabling personalized learning alone may be more appropriate than automatically enabling "secret mode" for existing desktop Mozc users for the following reasons:

• What MS-IME does for IS_PRIVATE is actually to disable personalized learning while keeping other personalized features intact.
• There is no visual indicator when the "secret mode" is enabled in the desktop renderer. Users would have no idea why conversion results are different only on the incognito mode in Chromium-based browsers and private-browsing mode in Firefox-based browsers.
• mozc.commands.Request has been implemented as a handler-global state, not per-session state. SessionHandler::SetRequest ignores the session id and pushes the new request onto every live session. Sent from one Windows app, is_incognito_mode would have leaked into all other apps' sessions on the shared mozc_server, which is not a desirable behavior.

With the above considerations, it seems more appropriate to interpret IS_PRIVATE/IBUS_INPUT_HINT_PRIVATE as a "no personalized learning" signal like how IME_FLAG_NO_PERSONALIZED_LEARNING is defined, even if Mozc for Android interpreted it as the "secret mode" signal instead.

Issue IDs

N/A

Steps to test new behaviors (if any)

• OS: Windows 11 25H2 / Chrome 152.0.7977.65
• Steps:
  1. Open a Chrome tab with Incognito mode enabled
  2. Enable Mozc
  3. Type "ちょうしんせいざんがい" then convert it to "超新星残骸"
  4. Type "ちょうしんせい" again
  5. Make sure that "超新星残骸" is not suggested

[yukawa]

Rebased onto master.

[yukawa]

Renamed ConversionRequest::history_learning_level() to ConversionRequest::effective_history_learning_level(). Other parts remain unchanged.

[yukawa]

To make discussion easier, I've sent out the following smaller changes that are split out from this one.

• Add TipInputModeManager::HasPrivateInputScope #1605
• Add IbusEngineWrapper::HasPrivateInputHint #1606

Then converting this into a draft until the above ones get merged.

[yukawa]

Rebased onto master.