fix(tests): stop AppKit rewriting the uppercase-key-equivalent fixture - #400
fix(tests): stop AppKit rewriting the uppercase-key-equivalent fixture#400skkap wants to merge 1 commit into
Conversation
testUppercaseKeyEquivalentReportsImpliedShift built its menu item with the title "Paste and Match Style". AppKit recognises that as a standard menu item and, on NSMenu.addItem, rewrites it to the system-standard equivalent -- so the fixture's uppercase "V" + [.command, .option] became "v" + [.command, .shift] before collectKeyEquivalents ever ran, and the test asserted cmd+opt+shift+v against an actual cmd+shift+v. The rewrite keys off the title alone: the same key and mask under a custom title are untouched, and the stock title with an entirely different key is rewritten just the same. Rename the fixture item and say why, so the test exercises the implied-shift path it describes. Product code is unchanged -- chordSyntax was always correct; the fixture was being mutated out from under it.
|
this is already fixed on master by 16d8cbc, merged a day before your commit. Your branch forks from 4155ed9 and is 15 commits behind, so it doesn't carry the fix. the cause isn't a standard-item table. AppKit substitutes renaming the fixture also doesn't generalize. The substitution keys on any title, not only stock ones, so 16d8cbc suppresses the substitution for the duration of each test class instead, closing this one. Rebase #398 on master and the failure goes with it. |
The guard lived only in the setUp of LiveMenuKeyEquivalentsTests and CloseSessionChordTests, so a new menu-fixture test hits the same trap with nothing in the rules to point at it. Records the mechanism, the defaults command that names the bindings, and why suppressing beats renaming fixtures. Related to #400.
2 participants
make test-appfails onLiveMenuKeyEquivalentsTests.testUppercaseKeyEquivalentReportsImpliedShift():Product code is fine — the fixture is mutated before the code under test runs.
Cause
The test builds its item with the title
"Paste and Match Style". AppKit recognises that as a standard menu item and, onNSMenu.addItem, rewrites it to the system-standard equivalent — so"V"+[.command, .option]becomes"v"+[.command, .shift].collectKeyEquivalentsthen correctly reportscmd+shift+vfor the item it was actually handed, and the assertion compares that against thecmd+opt+shift+vthe test believed it built.The rewrite keys off the title alone. Measured on macOS 26.5.2:
addItem"Paste and Match Style", key"V", mask[cmd, opt]"v", mask[cmd, shift]"Totally Custom Title", key"V", mask[cmd, opt]"V", mask[cmd, opt]— untouched"Paste and Match Style", key"Q", mask[cmd, opt]"v", mask[cmd, shift]The third row is the telling one: a completely different key equivalent is still replaced with ⇧⌘V, because the title is what AppKit matches on. Before
addItemthe item holds exactly what the test set, so the rewrite happens at insertion.It is not key-equivalent localization —
allowsAutomaticKeyEquivalentLocalization = falsemakes no difference — and it is not the chord logic, which never sees the original values.Fix
Rename the fixture item to a non-stock title, and record why in a comment so it does not get "corrected" back to a realistic-looking stock name. One line of test data;
chordSyntaxis untouched.After:
make test-appreports TEST SUCCEEDED, andswiftlint --strictstays at 0 violations across 326 files.Why it presumably passes in CI
I did not confirm this, so treat it as a guess: the rewrite depends on AppKit's standard-item table, so a different macOS version — or a different system language, since the match is against localized standard titles — would not fire it. Reproduced here on macOS 26.5.2 / Xcode 26, where it fails identically on unmodified
master(4155ed9).Split out of #398, which ran into it.