fix(input): fix AccessKeyHandler when no descendant control has focus - #21920
Merged
MrJul merged 3 commits intoAug 7, 2026
Conversation
- Update IsFocusWithinOwner to use routed event's Source instead of re-querying KeyboardDevice.Instance.FocusedElement - Allow access keys (Alt/mnemonics) to work immediately after Window opens when FocusedElement is null or owner itself - Update shared test helpers in AccessKeyHandlerTests to populate event Source Fixes AvaloniaUI#21806
AutumnYuanc
force-pushed
the
fix/issue-21806-menu-accesskey
branch
from
August 5, 2026 08:42
563e99b to
a75ad36
Compare
|
You can test this PR using the following package version. |
Collaborator
|
Contributor
Author
|
@cla-avalonia agree |
MrJul
requested changes
Aug 6, 2026
- Type IsFocusWithinOwner's owner parameter as InputElement (matching _owner) and drop the now-redundant `is Visual` check - Fix indentation in IsFocusWithinOwner - Add Should_Raise_AccessKey_When_Focus_Is_On_Descendant, covering the IsVisualAncestorOf branch by raising KeyDown/KeyUp on a descendant control instead of the owner - Revert the no-op Source assignment in the KeyDown/KeyUp test helpers - Shorten the comment in Should_Raise_Key_Events_For_Registered_Access_Key
Contributor
Author
|
Pushed a75ad36..9c0ffae addressing the review feedback:
@MrJul PTAL |
|
You can test this PR using the following package version. |
MrJul
enabled auto-merge
August 7, 2026 09:26
|
You can test this PR using the following package version. |
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
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.
What does the pull request do?
Fixes
AccessKeyHandlerso that Alt/mnemonic access keys work correctly even when nodescendant control has claimed keyboard focus yet — most notably right after a
Windowis opened, before the user has pressed Tab or clicked anything.
What is the current behavior?
AccessKeyHandler.OnPreviewKeyDown/OnKeyDownguard their logic behindIsFocusWithinOwner(_owner), which re-queriesKeyboardDevice.Instance.FocusedElementdirectly:
KeyboardDevice.Instance.FocusedElementisnull(nothing hasclaimed focus yet), so the pattern match
focusedElement is not InputElementfailsand
IsFocusWithinOwnerreturnsfalseimmediately.TopLevelitself as the focused element,Visual.IsVisualAncestorOfis a strict, non-reflexive ancestor check(
x.IsVisualAncestorOf(x)is alwaysfalse), soIsFocusWithinOwnerstill returnsfalsewhenFocusedElement == owner.In both cases
OnPreviewKeyDown/OnKeyDownreturn early, so pressing Alt does nothing:no access key underlines, no menu opening, no F10.
Meanwhile
KeyboardDevice.ProcessRawEventalready resolves the effective focusedelement as
FocusedElement ?? e.Root.FocusRootand uses that both as the routing targetand as
KeyEventArgs.Source— so the event does correctly reachAccessKeyHandler'shandlers on
_owner, it's only the internal guard that re-derives a different (andincomplete) answer from scratch.
What is the updated/expected behavior with this PR?
Access keys (Alt + underline display, Alt+letter, F10/menu opening) work immediately
after a window opens, without requiring a prior Tab press or mouse click. Tests have
been added.
How was the solution implemented (if it's not obvious)?
IsFocusWithinOwnernow takes the routed event'sSource(already resolved byKeyboardDevice.ProcessRawEventusing the sameFocusedElement ?? e.Root.FocusRootfallback) instead of independently re-reading
KeyboardDevice.Instance.FocusedElement.This avoids duplicating focus-resolution logic and fixes both underlying issues at once:
Sourceis nevernullfor a real key event, so the "nothing focused yet" case ishandled correctly.
ReferenceEquals(source, owner), fixing theIsVisualAncestorOfnon-reflexivity issue for the case where the owner itself holdsfocus.
The shared
KeyDown/KeyUptest helpers inAccessKeyHandlerTestshave been updated topopulate
Sourcethe same way production code does(
KeyboardDevice.Instance?.FocusedElement ?? target), since they previously never set it.Checklist
Breaking changes
None.
IsFocusWithinOwneris aprivatemethod; its signature change is not observablefrom outside
AccessKeyHandler.Obsoletions / Deprecations
None.
Fixed issues
Fixes #21806