Fix #20625: fix compiled binding DataContext inference in ItemTemplate - #21248
Merged
MrJul merged 4 commits intoMay 15, 2026
Conversation
…temTemplate The Sandbox repro failed with AVLN2100/AVLN2000 when compiled bindings were used with ItemTemplate and name-based DataContext access. Root causes: - No fallback DataContext type was inferred for the root object when x:DataType was absent. - Name-scope lookup could capture stale DataContext metadata from an unrelated traversal branch, causing #ListBoxRoot.DataContext to incorrectly resolve to the item type. Fixes: - Add root-level DataContext fallback inference in AvaloniaXamlIlDataContextTypeTransformer. - Update ScopeRegistrationFinder to resolve DataContext from the current ancestor stack when the matching name is found. - Preserve first-match semantics and prefer root namescope lookup before deferred scopes in name binding resolution. - Add and expand unit tests for ItemTemplate and nested namescope scenarios, including mismatched runtime DataContext behavior. Signed-off-by: João Cruz <joaosantaremdacruz@tecnico.ulisboa.pt>
|
You can test this PR using the following package version. |
Collaborator
|
Contributor
Author
|
@cla-avalonia agree |
MrJul
added
bug
area-xaml
area-bindings
backport-candidate-12.0.x
Member
This is not how data contexts work, this change should be completely removed from the PR. |
MrJul
reviewed
Apr 23, 2026
MrJul
requested changes
Apr 23, 2026
Address review feedback to reduce test complexity in XamlIlTests. This change removes per-test UserControl helper classes and command scaffolding that were not required to validate the compiler behavior. Tests now use inline XAML in each [Fact] and shared lightweight mock types for root and item data. The compiled binding scenarios are still covered, including root fallback inference and named DataContext resolution with ItemTemplate and nested namescopes, but with less boilerplate and better readability.
|
You can test this PR using the following package version. |
MrJul
requested changes
Apr 27, 2026
| // starting type for compiled bindings. Falling back to the root CLR type | ||
| // allows expressions to compile and avoids stale inference from unrelated | ||
| // branches, while runtime DataContext semantics remain unchanged. | ||
| inferredDataContextTypeNode = new AvaloniaXamlIlDataContextTypeMetadataNode(on, on.Type.GetClrType()); |
Member
There was a problem hiding this comment.
As mentioned, this change isn't related to the issue and isn't necessary. We do not want automatic inference to fall back to the root type.
Address review feedback by removing the automatic fallback inference to the root type in AvaloniaXamlIlDataContextTypeTransformer, as it is not necessary to fix the issue and is not desired behavior. Also removes the unit tests that validated this specific fallback.
|
You can test this PR using the following package version. |
MrJul
enabled auto-merge
May 15, 2026 11:34
|
You can test this PR using the following package version. |
MrJul
added this pull request to the merge queue
May 15, 2026
MrJul
added a commit
to MrJul/Avalonia
that referenced
this pull request
May 28, 2026
…temTemplate (AvaloniaUI#21248) * Fix AvaloniaUI#20625: fix compiled binding DataContext inference in ItemTemplate The Sandbox repro failed with AVLN2100/AVLN2000 when compiled bindings were used with ItemTemplate and name-based DataContext access. Root causes: - No fallback DataContext type was inferred for the root object when x:DataType was absent. - Name-scope lookup could capture stale DataContext metadata from an unrelated traversal branch, causing #ListBoxRoot.DataContext to incorrectly resolve to the item type. Fixes: - Add root-level DataContext fallback inference in AvaloniaXamlIlDataContextTypeTransformer. - Update ScopeRegistrationFinder to resolve DataContext from the current ancestor stack when the matching name is found. - Preserve first-match semantics and prefer root namescope lookup before deferred scopes in name binding resolution. - Add and expand unit tests for ItemTemplate and nested namescope scenarios, including mismatched runtime DataContext behavior. Signed-off-by: João Cruz <joaosantaremdacruz@tecnico.ulisboa.pt> * Fix AvaloniaUI#20625: simplify compiled binding regression tests Address review feedback to reduce test complexity in XamlIlTests. This change removes per-test UserControl helper classes and command scaffolding that were not required to validate the compiler behavior. Tests now use inline XAML in each [Fact] and shared lightweight mock types for root and item data. The compiled binding scenarios are still covered, including root fallback inference and named DataContext resolution with ItemTemplate and nested namescopes, but with less boilerplate and better readability. * Fix AvaloniaUI#20625: remove automatic DataContext fallback to root type Address review feedback by removing the automatic fallback inference to the root type in AvaloniaXamlIlDataContextTypeTransformer, as it is not necessary to fix the issue and is not desired behavior. Also removes the unit tests that validated this specific fallback. --------- Signed-off-by: João Cruz <joaosantaremdacruz@tecnico.ulisboa.pt> Co-authored-by: Julien Lebosquain <julien@lebosquain.net>
MrJul
added
backported-12.0.x
and removed
backport-candidate-12.0.x
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
4 participants
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.
The Sandbox repro failed with AVLN2100/AVLN2000 when compiled bindings were used with ItemTemplate and name-based DataContext access.
Root causes:
Fixes:
What does the pull request do?
This PR fixes an issue where shorthand DataContext bindings (introduced in Avalonia 11.3.0) fail to resolve correctly when preceded by an ItemTemplate within the same view. It addresses the compiled binding errors (AVLN2100 and AVLN2000) by correcting how the XAML compiler infers the data context type during scope registration and name lookup.
What is the current behavior?
Currently, if an ItemTemplate (such as one inside a ComboBox) is declared before an element using a shorthand DataContext binding (e.g., {Binding #ListBoxRoot.DataContext.ButtonCommand} inside a ListBox), the compiler incorrectly captures stale DataContext metadata from the unrelated traversal branch. It evaluates the target element's DataContext as matching the preceding ItemTemplate's context rather than the actual parent, causing the application to crash during compilation.
What is the updated/expected behavior with this PR?
The DataContext now correctly resolves to the parent element it is assigned to. Shorthand bindings placed after other ItemTemplate definitions no longer confuse the compiler's scope lookup, allowing the project to build and the bindings to resolve accurately.
How was the solution implemented (if it's not obvious)?
Added root-level DataContext fallback inference in AvaloniaXamlIlDataContextTypeTransformer to handle cases where x:DataType is absent.
Updated ScopeRegistrationFinder so that when a matching name is found, it resolves the DataContext from the current ancestor stack rather than capturing stale context from previous branches.
Preserved first-match semantics, giving preference to the root namescope lookup over deferred scopes during name binding resolution.
Added and expanded unit tests covering nested namescopes, ItemTemplate scenarios, and mismatched runtime DataContext behavior.
Checklist
Breaking changes
None.
Obsoletions / Deprecations
None.
Fixed issues
Fixes #20625