fix: post Eisu/Kana keys by default; TIS only for Affinity-class apps#117
Merged
Conversation
…apps v2.4.7 switched all apps to TISSelectInputSource. That broke single-mode IMEs (Google Japanese Input, ATOK): they expose one "base" input mode to TIS and toggle Hiragana/direct internally, so TIS moved the menu-bar indicator to Hiragana while typing stayed in direct/Roman input. Restore posting the Eisu(102)/Kana(104) virtual keys as the default — those drive the IME's internal mode correctly for every standard app. Keep the TIS switch only for a small set of apps (Affinity) whose text engine mishandles the synthesized key and leaks it as a literal space. Verified on-device: Google IME exposes com.google.inputmethod.Japanese.base (single KeyboardInputMode) — confirming TIS cannot drive its Hiragana mode. Added a skippable InputSourceDumpTests diagnostic to enumerate the real TIS structure of installed IMEs.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem (v2.4.7/2.4.8 regression)
v2.4.7 switched all apps to
TISSelectInputSource. That broke single-mode IMEs — Google Japanese Input (and ATOK): the menu bar showed Hiragana (あ) but typing stayed in direct/Roman input.Root cause (verified on-device): Google IME exposes only one input mode to TIS —
It toggles Hiragana ⇔ direct internally via the かな/英数 keys.
TISSelectInputSource(base)selects the IME (updates the menu-bar icon) but cannot drive that internal mode. Kotoeri works because it exposes separate mode sources; Google/ATOK do not.So the two requirements are mutually exclusive per-app: Affinity needs TIS (a posted key leaks as a space), Google needs the posted key (TIS can't change its mode).
Fix
InputSourceSwitcher.tisSwitchAppBundleIDs(Affinity family), where the posted key would leak. Tracked asisTISSwitchAppon frontmost-app activation.Tests
KeyEventTests: Kana/Eisu output passes through for a normal app (isTISSwitchApp=false) and is swallowed for a TIS-switch app (=true), on both keyDown and keyUp — this is exactly the behavior the prior tests failed to assert.InputSourceSwitcherTests: keycode predicate + Affinity in the app set + palette-avoidance regression (kept from 2.4.8).InputSourceDumpTests: skippable on-device diagnostic (CMDIME_DUMP_INPUT_SOURCES=1) that enumerates installed IMEs' TIS structure — how the root cause was found.swift buildclean · 38 tests (1 skipped, 0 failures) · swiftlint 0 serious.Version 2.4.9 (auto-release on merge).