ContentPresenter: Propagate binding context to children with explicit TemplateBinding

[HarishwaranVijayakumar]

Note

Are you waiting for the changes in this PR to be merged?
It would be very helpful if you could test the resulting artifacts from this PR and let us know in a comment if this change resolves your issue. Thank you!

Issue Details

When using a ContentPresenter with an explicit TemplateBinding to a custom BindableProperty in a ControlTemplate, child elements inside the ContentPresenter do not inherit the binding context. This causes data bindings (e.g. Command) to fail silently.

Repro: Create a ContentView subclass with a custom BindableProperty of type View (e.g. MyContent), use it in a ControlTemplate with ContentPresenter.ContentProperty explicitly bound to that property via TemplateBinding, and place a Button with a Command binding inside. The command will not fire.

Root Cause

ContentPresenter overrides SetChildInheritedBindingContext with an intentional no-op:

// We never want to use the standard inheritance mechanism, we will get this set by our parent

This design came from the Xamarin.Forms era where the binding context was assumed to be set through a different propagation path. With the default ContentPresenter behavior (content bound via ContentConverter on IContentView.Content), the binding context eventually propagates correctly because the ControlTemplate's content tree is wired up through ParentOverride and the templated parent.

However, with an explicit TemplateBinding to a custom BindableProperty, the binding resolves directly without going through the templated parent propagation path. The SetChildInheritedBindingContext override silently discards the inherited context, so child elements never receive the BindingContext from the templated parent.

Note: ContentConverter does NOT handle binding context — it only forwards text/font properties from ancestor elements.

Description of Change

src/Controls/src/Core/ContentPresenter.cs

Removed the no-op override in SetChildInheritedBindingContext and replaced it with an actual call to SetInheritedBindingContext(child, context).

This ensures that when binding context flows down the element tree to a ContentPresenter, its children receive the inherited context — matching the standard MAUI/WinUI behavior where DataContext always propagates through the template tree.

This is consistent with the direction taken in PR #26072, which committed to always propagating BindingContext through ControlTemplate hierarchies.

Key Technical Details

• SetChildInheritedBindingContext is called by the element tree's inherited binding context propagation mechanism when a parent's BindingContext changes.
• The ContentPresenter constructor sets up a default binding on ContentProperty using ContentConverter and RelativeBindingSource.TemplatedParent. This default path is NOT affected by this change.
• ContentConverter only handles text/font property propagation — it does not participate in BindingContext inheritance.
• The fix aligns ContentPresenter with standard SetInheritedBindingContext behavior used by all other layout types.

Issues Fixed

Fixes #23797

Platforms Tested

• Windows
• Android
• iOS
• Mac

[dotnet-policy-service]

Hey there @@HarishwaranVijayakumar! Thank you so much for your PR! Someone from the team will get assigned to your PR shortly and we'll get it reviewed.

[Copilot]

Pull Request Overview

This PR fixes a binding context inheritance issue in ContentPresenter when using explicit TemplateBinding in ControlTemplates. The problem occurred when ContentPresenter with explicit template bindings failed to properly propagate binding context to child elements, causing data bindings like Commands to fail.

Key Changes:

• Modified SetChildInheritedBindingContext method in ContentPresenter to ensure proper binding context propagation
• Added comprehensive UI test coverage to validate the fix across all platforms

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

File	Description
src/Controls/src/Core/ContentPresenter.cs	Core fix: Updated SetChildInheritedBindingContext to call SetInheritedBindingContext for proper context propagation
src/Controls/tests/TestCases.HostApp/Issues/Issue23797.cs	Added UI test page demonstrating ContentPresenter binding context issue with custom control and command binding
src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue23797.cs	Added automated NUnit test to verify binding context propagation works correctly

Comments suppressed due to low confidence (2)

src/Controls/tests/TestCases.HostApp/Issues/Issue23797.cs:10

• [nitpick] The property name 'Issue23797_ViewModel' is redundant and unclear. Consider renaming it to 'ViewModel' or 'SharedViewModel' for better readability.

    public static Issue23797_ViewModel Issue23797_ViewModel { get; } = new Issue23797_ViewModel();

src/Controls/tests/TestCases.HostApp/Issues/Issue23797.cs:52

• [nitpick] The class name 'CustomControlWithCustomContent_Issue23797' is overly verbose and unclear. Consider renaming it to 'CustomContentControl' or 'TestContentControl' for better readability.

public class CustomControlWithCustomContent_Issue23797 : ContentView

[mattleibow]

/azp run

[mattleibow]

Do we know why this comment is the exact opposite of this PR?

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[jsuarezruiz]

/rebase

[rmarinho]

🤖 AI Summary

📊 Expand Full Review

---

🔍 Pre-Flight — Context & Validation

---

📝 Review Session — Modified the testcase · 7c9297b

---

Issue: #23797 - Binding context in ContentPresenter
PR: #30880 - Fix for Binding context in ContentPresenter
Author: HarishwaranVijayakumar (Syncfusion partner)
Platforms Affected: All (Windows, Android, iOS, Mac) - cross-platform binding infrastructure
Files Changed: 1 implementation file, 2 test files

Issue Summary

When using a ContentPresenter with explicit TemplateBinding in a ControlTemplate, the binding context is not properly inherited by the content inside the ContentPresenter. This causes data bindings (like Commands) to fail.

Scenario:

• User creates a custom ContentView with a ControlTemplate using ContentPresenter
• User overrides the ContentProperty with an explicit TemplateBinding instead of the default
• Buttons placed inside the ContentPresenter have their CommandProperty bound to a ViewModel command
• The command never fires because binding context inheritance is broken for explicit template bindings

Root Cause: The SetChildInheritedBindingContext override in ContentPresenter previously had only a comment body (// We never want to use the standard inheritance mechanism, we will get this set by our parent), effectively making it a no-op. When using explicit TemplateBinding, the ContentConverter (which normally handles binding context propagation) is bypassed, so inheritance never happens.

PR Fix Analysis

Fix file: src/Controls/src/Core/ContentPresenter.cs (+1, -1)

The fix changes SetChildInheritedBindingContext from a no-op comment to actually calling SetInheritedBindingContext(child, context).

Before:

internal override void SetChildInheritedBindingContext(Element child, object context)
{
    // We never want to use the standard inheritance mechanism, we will get this set by our parent
}

After:

internal override void SetChildInheritedBindingContext(Element child, object context)
{
    SetInheritedBindingContext(child, context);
}

Reviewer Discussion

File:Line	Reviewer	Comment	Status
ContentPresenter.cs:107	mattleibow	"Do we know why this comment is the exact opposite of this PR?"	⚠️ OPEN (unanswered)

Key concern: The original comment explicitly said NOT to use standard inheritance. PR #26072 (referenced in the PR description) was a related fix for binding context propagation in ContentView → ControlTemplate, merged in .NET 9 SR2. The current PR extends that fix to the SetChildInheritedBindingContext path.

Note: The current working directory already has the PR's fix applied (the method calls SetInheritedBindingContext).

Fix Candidates

#	Source	Approach	Test Result	Files Changed	Notes
PR	PR #30880	Call SetInheritedBindingContext in SetChildInheritedBindingContext	⏳ PENDING (Gate)	ContentPresenter.cs (+1/-1)	Original PR

---

🚦 Gate — Test Verification

---

📝 Review Session — Modified the testcase · 7c9297b

---

Result: ✅ PASSED
Platform: android
Mode: Full Verification
Test Filter: Issue23797

Check	Expected	Actual	Result
Tests WITHOUT fix	FAIL	FAIL	✅
Tests WITH fix	PASS	PASS	✅

• Tests FAIL without fix ✅ (bug is present)
• Tests PASS with fix ✅ (bug is fixed)

Conclusion: The tests properly validate the fix and catch the bug when it's present.

---

🔧 Fix — Analysis & Comparison

---

📝 Review Session — Modified the testcase · 7c9297b

---

Fix Candidates

#	Source	Approach	Test Result	Files Changed	Notes
1	try-fix (manual)	Remove SetChildInheritedBindingContext override entirely	✅ PASS	ContentPresenter.cs	Equivalent to PR's fix - base Element class already calls SetInheritedBindingContext
2	try-fix (claude-opus-4.6)	Override OnBindingContextChanged + keep no-op SetChildInheritedBindingContext	❌ FAIL	ContentPresenter.cs	base.OnBindingContextChanged iterates logical children and calls the no-op, creating a dead-end
3	try-fix (manual)	Add SetInheritedBindingContext(newView, self.BindingContext) in OnContentChanged + keep no-op	✅ PASS (partial)	ContentPresenter.cs	Test passes but incomplete - doesn't handle BindingContext changes after content is set
PR	PR #30880	Call SetInheritedBindingContext(child, context) in SetChildInheritedBindingContext	✅ PASS (Gate)	ContentPresenter.cs (+1/-1)	Original PR - minimal, complete fix

Cross-Pollination Summary

Model	Round 2 Response
gpt-5.2-codex	NEW IDEA (already covered by existing AddLogicalChild calls)
gemini-3-pro-preview	NO NEW IDEAS
claude-sonnet-4.5	NEW IDEA (OnPropertyChanged for BC - same coverage gap as Attempt 3)
claude-opus-4.6	NO NEW IDEAS (analysis: solution space exhausted, PR fix is optimal)
gpt-5.2	NO NEW IDEAS

Exhausted: Yes - all 5 models confirmed no new complete ideas

Selected Fix: PR's fix - The PR's single-line change is the minimal, complete, and correct solution. It fixes SetChildInheritedBindingContext which is the single hook called by the framework for all inherited binding context scenarios. Attempt 1 (removing the override) is functionally equivalent but the PR's explicit override is better for documentation purposes. Attempt 3 is incomplete (misses BC changes after content set).

Root Cause Analysis

ContentPresenter.SetChildInheritedBindingContext was intentionally overridden to be a no-op with the comment: "We never want to use the standard inheritance mechanism, we will get this set by our parent". This was designed for the default ContentPresenter behavior where ContentConverter handles binding context propagation.

When using explicit TemplateBinding on ContentPresenter.ContentProperty, the ContentConverter is bypassed. This left children of ContentPresenter with no binding context propagation path, causing Commands bound to the ViewModel to fail.

The fix correctly enables standard inheritance by calling SetInheritedBindingContext(child, context), aligning ContentPresenter with its sibling ContentView which does the same thing.

Note on Try-Fix Models

Note: 3 of 5 model invocations via task agent failed due to API rate limiting (429). Those attempts were run manually within the main context.

---

📋 Report — Final Recommendation

---

📝 Review Session — Modified the testcase · 7c9297b

---

✅ Final Recommendation: APPROVE

Summary

PR #30880 fixes a binding context inheritance bug in ContentPresenter when using explicit TemplateBinding for ContentProperty. The fix is a minimal 1-line change that aligns ContentPresenter's behavior with ContentView and the base Element class. Gate testing confirms tests fail without the fix and pass with it. Multi-model try-fix exploration found no better alternative — the PR's approach is the minimal complete solution.

---

Root Cause

ContentPresenter.SetChildInheritedBindingContext was historically a no-op (with comment: "We never want to use the standard inheritance mechanism, we will get this set by our parent"). This was originally designed for the default ContentPresenter behavior where ContentConverter handled binding context propagation.

When users create multiple ContentPresenter slots with explicit TemplateBinding (bypassing ContentConverter), the standard inheritance path is not triggered. This left child views with no binding context, silently breaking all ViewModel-bound Commands.

This fix continues the direction of PR #26072 (merged in .NET 9 SR2), which changed ContentView to always propagate binding context to ControlTemplate.

---

Fix Quality

✅ Minimal and correct: The 1-line change (SetInheritedBindingContext(child, context)) is the only required fix. It makes ContentPresenter behave identically to:

• ContentView.SetChildInheritedBindingContext (same 1-line implementation)
• Element.SetChildInheritedBindingContext (the base class method)

✅ Tests pass verification: Gate confirmed tests FAIL without fix, PASS with fix on Android.

✅ Independent validation: Try-fix found that removing the override entirely (Attempt 1) is functionally equivalent, confirming the PR's fix is correct.

---

Reviewer Question Addressed

Reviewer mattleibow asked: "Do we know why this comment is the exact opposite of this PR?"

Answer: The original "We never want..." comment reflected Xamarin.Forms-era behavior where ContentConverter exclusively managed binding context for ContentPresenter. With PR #26072 changing the binding context propagation model to be more consistent (always propagate to ControlTemplate), the original no-op is now incorrect for the explicit-TemplateBinding use case. The fix is consistent with the direction established by PR #26072.

---

Fix Candidates Summary

#	Approach	Result	Notes
1	Remove override entirely	✅ PASS	Equivalent to PR's fix; less explicit
2	OnBindingContextChanged + no-op SetChildInheritedBindingContext	❌ FAIL	No propagation path
3	SetInheritedBindingContext in OnContentChanged + no-op	✅ PASS (partial)	Misses BC changes after content is set
PR	SetInheritedBindingContext in SetChildInheritedBindingContext	✅ PASS	Selected — minimal, complete, explicit

Selected Fix: PR's fix — it's the minimal, complete, and most self-documenting solution.

---

Minor Issues (Non-Blocking)

1. Static ViewModel in test (public static Issue23797_ViewModel): If this test is ever expanded with multiple test methods, the shared static state could cause flakiness. For a single test method, this is acceptable.

2. Missing newline at end of both test files: Issue23797.cs and the test file are missing a trailing newline. Minor code style issue.

3. Reviewer question unanswered: The PR discussion has an unanswered inline comment from mattleibow. The PR author should respond to explain why the original comment was intentionally reversed (context from PR Always propagate the BC to the ControlTemplate #26072).

---

Title & Description

• Title "Fix for Binding context in ContentPresenter" — Accurate but could be more precise (e.g., "Fix binding context inheritance in ContentPresenter for explicit TemplateBinding"). Acceptable as-is.
• Description — Has the required NOTE block, clear root cause analysis, and references PR Always propagate the BC to the ControlTemplate #26072 and issue Binding context in ContentPresenter #23797. Well-written.

---

📋 Expand PR Finalization Review

---

Title: ⚠️ Needs Update

Current: Fix for Binding context in ContentPresenter

Issues:

• Uses vague "Fix for" prefix (noise)
• Doesn't describe the specific behavior being fixed
• Doesn't capture what changed in the code

Recommended: ContentPresenter: Propagate binding context to children with explicit TemplateBinding

Description: ⚠️ Needs Update

• Uses vague "Fix for" prefix (noise)
• Doesn't describe the specific behavior being fixed
• Doesn't capture what changed in the code

✨ Suggested PR Description

[!NOTE]
Are you waiting for the changes in this PR to be merged?
It would be very helpful if you could test the resulting artifacts from this PR and let us know in a comment if this change resolves your issue. Thank you!

Issue Details

When using a ContentPresenter with an explicit TemplateBinding to a custom BindableProperty in a ControlTemplate, child elements inside the ContentPresenter do not inherit the binding context. This causes data bindings (e.g. Command) to fail silently.

Repro: Create a ContentView subclass with a custom BindableProperty of type View (e.g. MyContent), use it in a ControlTemplate with ContentPresenter.ContentProperty explicitly bound to that property via TemplateBinding, and place a Button with a Command binding inside. The command will not fire.

Root Cause

ContentPresenter overrides SetChildInheritedBindingContext with an intentional no-op:

// We never want to use the standard inheritance mechanism, we will get this set by our parent

This design came from the Xamarin.Forms era where the binding context was assumed to be set through a different propagation path. With the default ContentPresenter behavior (content bound via ContentConverter on IContentView.Content), the binding context eventually propagates correctly because the ControlTemplate's content tree is wired up through ParentOverride and the templated parent.

However, with an explicit TemplateBinding to a custom BindableProperty, the binding resolves directly without going through the templated parent propagation path. The SetChildInheritedBindingContext override silently discards the inherited context, so child elements never receive the BindingContext from the templated parent.

Note: ContentConverter does NOT handle binding context — it only forwards text/font properties from ancestor elements.

Description of Change

src/Controls/src/Core/ContentPresenter.cs

Removed the no-op override in SetChildInheritedBindingContext and replaced it with an actual call to SetInheritedBindingContext(child, context).

This ensures that when binding context flows down the element tree to a ContentPresenter, its children receive the inherited context — matching the standard MAUI/WinUI behavior where DataContext always propagates through the template tree.

This is consistent with the direction taken in PR #26072, which committed to always propagating BindingContext through ControlTemplate hierarchies.

Key Technical Details

• SetChildInheritedBindingContext is called by the element tree's inherited binding context propagation mechanism when a parent's BindingContext changes.
• The ContentPresenter constructor sets up a default binding on ContentProperty using ContentConverter and RelativeBindingSource.TemplatedParent. This default path is NOT affected by this change.
• ContentConverter only handles text/font property propagation — it does not participate in BindingContext inheritance.
• The fix aligns ContentPresenter with standard SetInheritedBindingContext behavior used by all other layout types.

Issues Fixed

Fixes #23797

Platforms Tested

• Windows
• Android
• iOS
• Mac

Code Review: ⚠️ Issues Found

Code Review — PR #30880

🔴 Critical Issues

Inaccurate Root Cause in Description (Description Correctness)

• File: PR description
• Problem: The description claims the ContentConverter was "responsible for preserving binding context inheritance" and that explicit TemplateBinding "bypasses this converter." This is factually incorrect. ContentConverter only handles text/font property propagation (see ContentConverter.cs — ConfigureView/BindTextProperties/BindFontProperties). It has nothing to do with BindingContext inheritance. This misunderstanding could mislead future developers.
• Recommendation: Update description to correctly explain that the SetChildInheritedBindingContext no-op was the actual suppressor of binding context propagation.

Unaddressed Open Reviewer Concern

• File: PR review thread
• Problem: Reviewer mattleibow asked "Do we know why this comment is the exact opposite of this PR?" This question is still open and unresolved. The original comment was intentional Xamarin.Forms-era design. The PR should explicitly explain why this design decision is now safe to reverse, especially with context from PR Always propagate the BC to the ControlTemplate #26072.
• Recommendation: Author should respond to this review comment with an explanation, and that explanation should be reflected in the PR description.

---

🟡 Suggestions

Missing end-of-file newlines in test files

• Files:
  • src/Controls/tests/TestCases.HostApp/Issues/Issue23797.cs
  • src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue23797.cs
• Problem: Both new files are missing a trailing newline (\ No newline at end of file in the diff).
• Recommendation: Add newlines at the end of both files for consistency with the rest of the codebase.

Test category may not be the most specific

• File: src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue23797.cs (line 16)
• Problem: [Category(UITestCategories.Layout)] is used, but the test is specifically about ContentPresenter binding context in a ControlTemplate. A more specific category like ControlTemplate or BindingContext might exist.
• Recommendation: Verify available UITestCategories values and use the most specific one. Layout is acceptable if no better match exists.

Static ViewModel on the page class

• File: src/Controls/tests/TestCases.HostApp/Issues/Issue23797.cs (line 11)
• Problem: public static Issue23797_ViewModel Issue23797_ViewModel { get; } = new Issue23797_ViewModel(); — using a static property on a ContentPage subclass is unusual for test pages. If tests run in a shared process or multiple test runs re-use the page type, the static ViewModel state (Message = "failure") would persist and could cause false negatives on a second run.
• Recommendation: Move the ViewModel instantiation to the constructor (non-static), or reset state in a setup method.

---

✅ Looks Good

• Single focused change: The core fix is minimal (1 line changed) and targeted — replaces the intentional no-op with the correct propagation call.
• Test coverage: Both a HostApp UI page and a TestCases.Shared.Tests NUnit test are included, following the two-project requirement for UI tests.
• C# only HostApp test: The HostApp test correctly uses pure C# (no XAML) as preferred.
• AutomationId usage: AutomationId values (Issue23797Btn, CurrentMessageLabel) are consistently defined in the host page and referenced in the NUnit test.
• Issue attribute: [Issue(IssueTracker.Github, 23797, ...)] correctly links to the bug report.
• NOTE block: The PR description includes the required NOTE block at the top.
• Cross-platform testing: All four platforms (Windows, Android, iOS, Mac) are checked in the tested platforms list.

---