Fix TabBarIsVisible Not Updating Dynamically When Set on ShellContent

[Vignesh-SF3580]

Issue Detail

Shell.TabBarIsVisible does not update dynamically when set on ShellContent, even when using binding.

Root Cause

There were two gaps in the existing implementation:

1. Initial value: In ShellItem.ShowTabs, the effective value of TabBarIsVisible was resolved starting from displayedPage — it never walked up to ShellContent. So if the property was only set on a ShellContent (not on the page), it was silently ignored.

2. Dynamic updates: In ShellElementCollection.BaseShellItemPropertyChanged, only BaseShellItem.IsVisible changes triggered visibility re-evaluation. Changes to Shell.TabBarIsVisibleProperty on ShellContent were not handled at all, so bindings on ShellContent had no effect at runtime.

Description of Change

src/Controls/src/Core/Shell/ShellItem.cs — IShellItemController.ShowTabs getter:

• Retrieves the current ShellContent via CurrentItem?.CurrentItem
• If TabBarIsVisible is explicitly set on the ShellContent, passes shellContent (instead of displayedPage) as the element to GetEffectiveValue
• This ensures ShellContent-level values take priority in the lookup chain

src/Controls/src/Core/Shell/ShellElementCollection.cs — BaseShellItemPropertyChanged:

• Added an else if branch to handle Shell.TabBarIsVisibleProperty changes on ShellContent senders
• On change: walks up to the parent Shell, gets the currently displayed page, and checks whether that page belongs to the changed ShellContent
• If it does and the values differ, calls Shell.SetTabBarIsVisible(displayedPage, shellContentValue) to sync the value to the active page, triggering a UI refresh

Tested the behavior in the following platforms

• Android
• Windows
• iOS
• Mac

Issues Fixed

Fixes #32994

Screenshots

Android:

Before Issue Fix	After Issue Fix
32994Android.mov	32994AndroidFix.mov

iOS:

Before Issue Fix	After Issue Fix
32994iOS.mov	32994iOSFix.mov

[github-actions]

🚀 Dogfood this PR with:

⚠️ WARNING: Do not do this without first carefully reviewing the code of this PR to satisfy yourself it is safe.

curl -fsSL https://raw.githubusercontent.com/dotnet/maui/main/eng/scripts/get-maui-pr.sh | bash -s -- 33090

Or

• Run remotely in PowerShell:

iex "& { $(irm https://raw.githubusercontent.com/dotnet/maui/main/eng/scripts/get-maui-pr.ps1) } 33090"

[sheiksyedm]

/azp run maui-pr-uitests, maui-pr-devicetests

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[Copilot]

Pull request overview

Fixes a Shell behavior gap where Shell.TabBarIsVisible set (or bound) on ShellContent was ignored for dynamic updates, preventing the TabBar from hiding/showing at runtime as expected (issue #32994).

Changes:

• Update ShellItem.ShowTabs resolution to consider TabBarIsVisible on the active ShellContent.
• Add propagation logic to keep the displayed page in sync when TabBarIsVisible changes on ShellContent.
• Add a HostApp repro page + Appium UI tests and snapshot baselines for the scenario.

Reviewed changes

Copilot reviewed 4 out of 8 changed files in this pull request and generated 5 comments.

Show a summary per file

File	Description
src/Controls/src/Core/Shell/ShellItem.cs	Adjusts ShowTabs effective-value lookup to account for TabBarIsVisible set on the active ShellContent.
src/Controls/src/Core/Shell/ShellElementCollection.cs	Adds a PropertyChanged hook to react to TabBarIsVisible changes on ShellContent and update the current UI state.
src/Controls/tests/TestCases.HostApp/Issues/Issue32994.cs	Adds a repro Shell + pages + view model to toggle TabBarIsVisible via direct set and binding.
src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue32994.cs	Adds Appium-based regression UI tests to validate TabBar visibility updates.
src/Controls/tests/TestCases.Android.Tests/snapshots/android/TabBarVisibilityHidesOnPage1UsingDirectSet.png	Android snapshot baseline for hiding TabBar via direct set.
src/Controls/tests/TestCases.Android.Tests/snapshots/android/TabBarVisibilityHidesOnPage2UsingBinding.png	Android snapshot baseline for hiding TabBar via binding.
src/Controls/tests/TestCases.iOS.Tests/snapshots/ios/TabBarVisibilityHidesOnPage2UsingBinding.png	iOS snapshot baseline for hiding TabBar via binding.

[rmarinho]

🤖 AI Summary

📊 Expand Full Review

---

🔍 Pre-Flight — Context & Validation

---

📝 Review Session — added android images. · 9a92f95

---

Issue: #32994 - Shell.TabBarIsVisible is not updated dynamically at runtime
PR: #33090 - Fix TabBarIsVisible Not Updating Dynamically When Set on ShellContent
Author: Vignesh-SF3580 (community contributor, Syncfusion partner)
Platforms Affected: iOS, Android, Windows, MacCatalyst

Issue Summary

When Shell.TabBarIsVisible attached property is set on ShellContent (either directly or via data binding), the TabBar does not hide/show dynamically at runtime. The issue only occurred with ShellContent; setting it on a Page worked fine.

Root Cause (from PR description)

1. ShowTabs in ShellItem always resolved the value from the displayedPage, ignoring values set on ShellContent
2. When TabBarIsVisible changed on ShellContent at runtime, no notification was propagated to trigger a UI update

Files Changed

Fix files (2):

• src/Controls/src/Core/Shell/ShellItem.cs (+11/-1) - Read TabBarIsVisible from ShellContent when it has a value set
• src/Controls/src/Core/Shell/ShellElementCollection.cs (+27/-0) - Handle property change events on ShellContent and sync to displayed page

Test files (2 + 4 snapshots):

• src/Controls/tests/TestCases.HostApp/Issues/Issue32994.cs (+196) - HostApp page with direct set and binding scenarios
• src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue32994.cs (+74) - NUnit UI tests with 4 test methods
• 2x Android snapshots + 2x iOS snapshots

PR Discussion / Reviewer Feedback (from copilot-pull-request-reviewer)

File:Line	Reviewer Comment	Status
ShellItem.cs:139	Page value should take precedence over ShellContent (check displayedPage.IsSet() first)	⚠️ INVESTIGATE
ShellElementCollection.cs:277	Setting local value on displayedPage is intrusive; better to call shell.CurrentItem?.Handler?.UpdateValue(...)	⚠️ INVESTIGATE
ShellElementCollection.cs:257	Comment formatting: missing space after //	Minor
Issue32994.cs:63	Fields should be private readonly	Minor
Issue32994.cs:49	Windows #if branch needs explaining comment	Minor

Fix Candidates Table

#	Source	Approach	Test Result	Files Changed	Notes
PR	PR #33090	Read TabBarIsVisible from ShellContent if set; sync changes to displayed page via Shell.SetTabBarIsVisible	⏳ PENDING (Gate)	ShellItem.cs, ShellElementCollection.cs	Original PR

---

🚦 Gate — Test Verification

---

📝 Review Session — added android images. · 9a92f95

---

Result: ✅ PASSED
Platform: android
Mode: Full Verification

• Tests FAIL without fix ✅
• Tests PASS with fix ✅

Fix Files Validated:

• src/Controls/src/Core/Shell/ShellElementCollection.cs
• src/Controls/src/Core/Shell/ShellItem.cs

Total Tests Run: 4 (all passed with fix)

---

🔧 Fix — Analysis & Comparison

---

📝 Review Session — added android images. · 9a92f95

---

Fix Candidates

#	Source	Approach	Test Result	Files Changed	Notes
1	try-fix (sonnet-4.6)	Unconditionally use shellContent as starting element in GetEffectiveValue (instead of displayedPage) + sync TabBarIsVisible changes to displayed page in ShellElementCollection	✅ PASS	ShellItem.cs, ShellElementCollection.cs	Key insight: MAUI's lazy propagation from ShellContent→Page creates stale values; always using ShellContent avoids this
PR	PR #33090	Read TabBarIsVisible from ShellContent when shellContent.IsSet(TabBarIsVisible) + sync changes via Shell.SetTabBarIsVisible(displayedPage)	✅ PASS (Gate)	ShellItem.cs, ShellElementCollection.cs	Original PR; minor difference: conditional IsSet check

Note: Remaining 4 model attempts (claude-haiku-4.5, gpt-4.1, etc.) were skipped due to token rate limits.

Exhausted: No (token limit hit — 4 of 5 models not run)
Selected Fix: PR's fix — both approaches pass, PR's IsSet check adds a useful guard and the approach is solid. However, the precedence order in ShellItem.cs should be inverted (check displayedPage.IsSet first, then fall back to shellContent) to match standard Shell property resolution semantics.

---

📋 Report — Final Recommendation

---

📝 Review Session — added android images. · 9a92f95

---

⚠️ Final Recommendation: REQUEST CHANGES

Summary

PR #33090 fixes a real, verified bug where Shell.TabBarIsVisible set on ShellContent (either directly or via binding) was not honored at runtime. The fix passes all 4 UI tests on Android. However, there is a meaningful correctness issue in ShellItem.cs around property precedence that should be addressed before merging.

Root Cause

ShellItem.ShowTabs called GetEffectiveValue<bool>(TabBarIsVisibleProperty, ..., displayedPage) which starts the walk at the displayed Page and goes up: Page → ShellSection → ShellItem → Shell. This completely skips ShellContent in the hierarchy (Page is a child of ShellContent, but the walk goes UP from Page, not DOWN from ShellContent). So any value set on ShellContent was invisible.

Fix Quality Assessment

What works well:

• The two-part approach is conceptually correct: (1) fix the initial value read in ShowTabs, (2) propagate runtime changes from ShellContent to the displayed page
• Tests cover both direct set and binding scenarios, on Page1 and Page2 tabs
• The IShellContentController.Page == displayedPage guard correctly limits propagation to only the currently displayed tab's content

Correctness concern in ShellItem.cs (line 144):

// PR's logic: shellContent wins when it has a value set
if (shellContent is not null && shellContent.IsSet(Shell.TabBarIsVisibleProperty))
{
    currentPage = shellContent;
}
return shell.GetEffectiveValue<bool>(..., currentPage);

This logic means: if both displayedPage AND shellContent have TabBarIsVisible set, the shellContent value wins and the page value is silently ignored. In MAUI's attached property resolution pattern, a more specific element (closer to the content) should be able to override its parent. The displayed Page is conceptually the most specific element — if a developer explicitly calls Shell.SetTabBarIsVisible(page, true) on the page, it should override what the parent ShellContent specifies.

The reviewer's suggestion is correct: check displayedPage.IsSet(TabBarIsVisibleProperty) first, and only fall back to shellContent when the page doesn't have a local value:

Element currentPage = displayedPage;
if (shellContent is not null && !displayedPage.IsSet(Shell.TabBarIsVisibleProperty) && shellContent.IsSet(Shell.TabBarIsVisibleProperty))
{
    currentPage = shellContent;
}

Other reviewer comments (minor):

• Comment formatting in ShellElementCollection.cs:257: //When → // When (missing space)
• _page1Content and _viewModel fields in test code should be private readonly
• The Windows #if branch in tests needs a comment explaining why navigation differs

Alternative fix explored (try-fix Attempt 1, ✅ PASS):
Unconditionally using shellContent ?? displayedPage as the start element. This avoids the precedence issue but removes the ability for displayedPage to ever "win". Neither approach is fully correct without the !displayedPage.IsSet() guard.

Suggested Changes

Required:

// ShellItem.cs - fix precedence: Page value should win over ShellContent
var shellContent = CurrentItem?.CurrentItem;
Element currentPage = displayedPage;

// Fall back to shellContent only when page doesn't have a local value
if (shellContent is not null && !displayedPage.IsSet(Shell.TabBarIsVisibleProperty) && shellContent.IsSet(Shell.TabBarIsVisibleProperty))
{
    currentPage = shellContent;
}

return shell.GetEffectiveValue<bool>(Shell.TabBarIsVisibleProperty, () => defaultShowTabs, null, currentPage);

Optional (minor):

• Fix comment formatting (// When dynamically... not //When...)
• Make test fields private readonly
• Add comment explaining Windows #if in test

---

📋 Expand PR Finalization Review

---

Title: ✅ Good

Current: Fix TabBarIsVisible Not Updating Dynamically When Set on ShellContent

Description: ✅ Good

Description needs updates. See details below.

✨ 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 Detail

Shell.TabBarIsVisible does not update dynamically when set on ShellContent, even when using binding.

Root Cause

There were two gaps in the existing implementation:

1. Initial value: In ShellItem.ShowTabs, the effective value of TabBarIsVisible was resolved starting from displayedPage — it never walked up to ShellContent. So if the property was only set on a ShellContent (not on the page), it was silently ignored.

2. Dynamic updates: In ShellElementCollection.BaseShellItemPropertyChanged, only BaseShellItem.IsVisible changes triggered visibility re-evaluation. Changes to Shell.TabBarIsVisibleProperty on ShellContent were not handled at all, so bindings on ShellContent had no effect at runtime.

Description of Change

src/Controls/src/Core/Shell/ShellItem.cs — IShellItemController.ShowTabs getter:

• Retrieves the current ShellContent via CurrentItem?.CurrentItem
• If TabBarIsVisible is explicitly set on the ShellContent, passes shellContent (instead of displayedPage) as the element to GetEffectiveValue
• This ensures ShellContent-level values take priority in the lookup chain

src/Controls/src/Core/Shell/ShellElementCollection.cs — BaseShellItemPropertyChanged:

• Added an else if branch to handle Shell.TabBarIsVisibleProperty changes on ShellContent senders
• On change: walks up to the parent Shell, gets the currently displayed page, and checks whether that page belongs to the changed ShellContent
• If it does and the values differ, calls Shell.SetTabBarIsVisible(displayedPage, shellContentValue) to sync the value to the active page, triggering a UI refresh

Tested the behavior in the following platforms

• Android
• Windows
• iOS
• Mac

Issues Fixed

Fixes #32994

Code Review: ✅ Passed

Code Review — PR #33090

🟡 Suggestions

1. Inline #if Directives in UI Test Methods

File: src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue32994.cs
Tests affected: TabBarVisibilityShowsOnPage2UsingBinding, TabBarVisibilityHidesOnPage2UsingBinding

The repo guidelines explicitly prohibit inline #if ANDROID, #if WINDOWS, etc. in test methods. Platform-specific logic must be moved to extension methods.

Current (problematic):

[Test, Order(3)]
[Category(UITestCategories.Shell)]
public void TabBarVisibilityShowsOnPage2UsingBinding()
{
#if WINDOWS
    App.WaitForElement("ShowPage2TabBar");
    App.Tap("ShowPage2TabBar");
    App.TapTab("Tab1");
    App.WaitForElement("Page2");
    App.Tap("Page2");
    App.WaitForElement("Tab1");
#else
    App.WaitForElement("ShowPage2TabBar");
    App.Tap("ShowPage2TabBar");
    App.TapTab("Page2");
    App.WaitForElement("Tab1");
#endif
}

The difference between Windows and other platforms is how tabs are navigated (Windows uses TapTab("Tab1") + Tap("Page2") while others use TapTab("Page2")). This should be extracted into a cross-platform extension method, or the platform detection moved to a helper.

Recommendation: Extract the platform-specific tab navigation into a helper method (e.g., App.TapShellTab("Page2")) similar to what exists in the repo's Appium extension library.

---

2. Ordered Tests Create State Dependencies

File: src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue32994.cs

All four tests use [Test, Order(N)]. The tests rely on state left by prior tests — for example:

• Test 3 (TabBarVisibilityShowsOnPage2UsingBinding) relies on the tab bar having been hidden and then restored by Tests 1 and 2.
• Test 4 (TabBarVisibilityHidesOnPage2UsingBinding) navigates to Page1 and sets the binding value before switching to Page2.

This means if Test 1 fails, Tests 3 and 4 may produce unreliable results. Ordered tests also run in alphabetical order by default unless the test runner honors [Order], so this relies on NUnit respecting the ordering attribute.

Recommendation: Make each test self-contained by navigating to the initial state at the beginning of each test, rather than relying on the previous test's end state.

---

3. Missing Windows/MacCatalyst Snapshots for Screenshot Tests

Tests: TabBarVisibilityHidesOnPage1UsingDirectSet, TabBarVisibilityHidesOnPage2UsingBinding

Snapshots are provided for Android and iOS only. There are no snapshot images for Windows or MacCatalyst in TestCases.Windows.Tests or similar. The VerifyScreenshot() calls in the tests will run on all platforms, so Windows and MacCatalyst will attempt screenshot comparison and may fail if no baseline exists.

Note: This may be intentional if Windows/MacCatalyst tests aren't run in CI for this suite, but worth confirming.

---

4. Minor: Comment Missing Space After //

File: src/Controls/src/Core/Shell/ShellElementCollection.cs, line ~254

//When dynamically updating TabBarIsVisible through ShellContent

Should be:

// When dynamically updating TabBarIsVisible through ShellContent

This is a cosmetic issue but inconsistent with the surrounding code style.

---

✅ Looks Good

Core Fix Logic is Correct and Well-Scoped

ShellItem.cs — The initial-value fix is minimal and clean:

var shellContent = CurrentItem?.CurrentItem;
Element currentPage = displayedPage;

if (shellContent is not null && shellContent.IsSet(Shell.TabBarIsVisibleProperty))
{
    currentPage = shellContent;
}

return shell.GetEffectiveValue<bool>(Shell.TabBarIsVisibleProperty, () => defaultShowTabs, null, currentPage);

• Falls through to displayedPage behavior unchanged when ShellContent doesn't have the property set — no regression risk for existing usage.
• Correctly uses IsSet rather than GetValue to distinguish "explicitly set" from "default value".

ShellElementCollection.cs — The dynamic-update fix is also well-guarded:

• Verifies sender is ShellContent before acting.
• Walks up to the parent Shell to get the current page — no hardcoded assumptions.
• Checks contentController.Page == displayedPage to ensure the ShellContent owns the current page before propagating — avoids updating visibility when the user is on a different tab.
• Compares old and new values (shellContentValue != pageValue) before calling SetTabBarIsVisible, avoiding unnecessary property change cascades.

Test HostApp Coverage is Comprehensive

Issue32994.cs in TestCases.HostApp tests two distinct scenarios:

1. Direct set (Shell.SetTabBarIsVisible(_page1Content, ...)) — validates the ShellItem.cs path
2. Binding update (_viewModel.TabBarIsVisible = ...) — validates the ShellElementCollection.cs path

The ViewModel is a proper INotifyPropertyChanged implementation, making this a realistic binding test.

IShellContentController Cast is Safe

In ShellElementCollection.cs, the pattern shellContent is IShellContentController contentController is used after sender is ShellContent shellContent. Since ShellContent always implements IShellContentController, the cast will always succeed. This is not a bug — it's just slightly verbose but acceptable.

---

[Vignesh-SF3580]

🤖 AI Summary

📊 Expand Full Review
🔍 Pre-Flight — Context & Validation
📝 Review Session — added android images. · 9a92f95
Issue: #32994 - Shell.TabBarIsVisible is not updated dynamically at runtime PR: #33090 - Fix TabBarIsVisible Not Updating Dynamically When Set on ShellContent Author: Vignesh-SF3580 (community contributor, Syncfusion partner) Platforms Affected: iOS, Android, Windows, MacCatalyst

Issue Summary

When Shell.TabBarIsVisible attached property is set on ShellContent (either directly or via data binding), the TabBar does not hide/show dynamically at runtime. The issue only occurred with ShellContent; setting it on a Page worked fine.

Root Cause (from PR description)

1. ShowTabs in ShellItem always resolved the value from the displayedPage, ignoring values set on ShellContent
2. When TabBarIsVisible changed on ShellContent at runtime, no notification was propagated to trigger a UI update

Files Changed

Fix files (2):

• src/Controls/src/Core/Shell/ShellItem.cs (+11/-1) - Read TabBarIsVisible from ShellContent when it has a value set
• src/Controls/src/Core/Shell/ShellElementCollection.cs (+27/-0) - Handle property change events on ShellContent and sync to displayed page

Test files (2 + 4 snapshots):

• src/Controls/tests/TestCases.HostApp/Issues/Issue32994.cs (+196) - HostApp page with direct set and binding scenarios
• src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue32994.cs (+74) - NUnit UI tests with 4 test methods
• 2x Android snapshots + 2x iOS snapshots

PR Discussion / Reviewer Feedback (from copilot-pull-request-reviewer)

File:Line Reviewer Comment Status
ShellItem.cs:139 Page value should take precedence over ShellContent (check displayedPage.IsSet() first) ⚠️ INVESTIGATE
ShellElementCollection.cs:277 Setting local value on displayedPage is intrusive; better to call shell.CurrentItem?.Handler?.UpdateValue(...) ⚠️ INVESTIGATE
ShellElementCollection.cs:257 Comment formatting: missing space after // Minor
Issue32994.cs:63 Fields should be private readonly Minor
Issue32994.cs:49 Windows #if branch needs explaining comment Minor

Fix Candidates Table

Source Approach Test Result Files Changed Notes

PR PR #33090 Read TabBarIsVisible from ShellContent if set; sync changes to displayed page via Shell.SetTabBarIsVisible ⏳ PENDING (Gate) ShellItem.cs, ShellElementCollection.cs Original PR
🚦 Gate — Test Verification
📝 Review Session — added android images. · 9a92f95
Result: ✅ PASSED Platform: android Mode: Full Verification

• Tests FAIL without fix ✅
• Tests PASS with fix ✅

Fix Files Validated:

• src/Controls/src/Core/Shell/ShellElementCollection.cs
• src/Controls/src/Core/Shell/ShellItem.cs

Total Tests Run: 4 (all passed with fix)

🔧 Fix — Analysis & Comparison
📝 Review Session — added android images. · 9a92f95

Fix Candidates

Source Approach Test Result Files Changed Notes

1 try-fix (sonnet-4.6) Unconditionally use shellContent as starting element in GetEffectiveValue (instead of displayedPage) + sync TabBarIsVisible changes to displayed page in ShellElementCollection ✅ PASS ShellItem.cs, ShellElementCollection.cs Key insight: MAUI's lazy propagation from ShellContent→Page creates stale values; always using ShellContent avoids this
PR PR #33090 Read TabBarIsVisible from ShellContent when shellContent.IsSet(TabBarIsVisible) + sync changes via Shell.SetTabBarIsVisible(displayedPage) ✅ PASS (Gate) ShellItem.cs, ShellElementCollection.cs Original PR; minor difference: conditional IsSet check
Note: Remaining 4 model attempts (claude-haiku-4.5, gpt-4.1, etc.) were skipped due to token rate limits.

Exhausted: No (token limit hit — 4 of 5 models not run) Selected Fix: PR's fix — both approaches pass, PR's IsSet check adds a useful guard and the approach is solid. However, the precedence order in ShellItem.cs should be inverted (check displayedPage.IsSet first, then fall back to shellContent) to match standard Shell property resolution semantics.

📋 Report — Final Recommendation
📝 Review Session — added android images. · 9a92f95

⚠️ Final Recommendation: REQUEST CHANGES

Summary

PR #33090 fixes a real, verified bug where Shell.TabBarIsVisible set on ShellContent (either directly or via binding) was not honored at runtime. The fix passes all 4 UI tests on Android. However, there is a meaningful correctness issue in ShellItem.cs around property precedence that should be addressed before merging.

Root Cause

ShellItem.ShowTabs called GetEffectiveValue<bool>(TabBarIsVisibleProperty, ..., displayedPage) which starts the walk at the displayed Page and goes up: Page → ShellSection → ShellItem → Shell. This completely skips ShellContent in the hierarchy (Page is a child of ShellContent, but the walk goes UP from Page, not DOWN from ShellContent). So any value set on ShellContent was invisible.

Fix Quality Assessment

What works well:

• The two-part approach is conceptually correct: (1) fix the initial value read in ShowTabs, (2) propagate runtime changes from ShellContent to the displayed page
• Tests cover both direct set and binding scenarios, on Page1 and Page2 tabs
• The IShellContentController.Page == displayedPage guard correctly limits propagation to only the currently displayed tab's content

Correctness concern in ShellItem.cs (line 144):

// PR's logic: shellContent wins when it has a value set
if (shellContent is not null && shellContent.IsSet(Shell.TabBarIsVisibleProperty))
{
    currentPage = shellContent;
}
return shell.GetEffectiveValue<bool>(..., currentPage);

This logic means: if both displayedPage AND shellContent have TabBarIsVisible set, the shellContent value wins and the page value is silently ignored. In MAUI's attached property resolution pattern, a more specific element (closer to the content) should be able to override its parent. The displayed Page is conceptually the most specific element — if a developer explicitly calls Shell.SetTabBarIsVisible(page, true) on the page, it should override what the parent ShellContent specifies.

The reviewer's suggestion is correct: check displayedPage.IsSet(TabBarIsVisibleProperty) first, and only fall back to shellContent when the page doesn't have a local value:

Element currentPage = displayedPage;
if (shellContent is not null && !displayedPage.IsSet(Shell.TabBarIsVisibleProperty) && shellContent.IsSet(Shell.TabBarIsVisibleProperty))
{
    currentPage = shellContent;
}

Other reviewer comments (minor):

• Comment formatting in ShellElementCollection.cs:257: //When → // When (missing space)
• _page1Content and _viewModel fields in test code should be private readonly
• The Windows #if branch in tests needs a comment explaining why navigation differs

Alternative fix explored (try-fix Attempt 1, ✅ PASS): Unconditionally using shellContent ?? displayedPage as the start element. This avoids the precedence issue but removes the ability for displayedPage to ever "win". Neither approach is fully correct without the !displayedPage.IsSet() guard.

Suggested Changes

Required:

// ShellItem.cs - fix precedence: Page value should win over ShellContent
var shellContent = CurrentItem?.CurrentItem;
Element currentPage = displayedPage;

// Fall back to shellContent only when page doesn't have a local value
if (shellContent is not null && !displayedPage.IsSet(Shell.TabBarIsVisibleProperty) && shellContent.IsSet(Shell.TabBarIsVisibleProperty))
{
    currentPage = shellContent;
}

return shell.GetEffectiveValue<bool>(Shell.TabBarIsVisibleProperty, () => defaultShowTabs, null, currentPage);

Optional (minor):

• Fix comment formatting (// When dynamically... not //When...)
• Make test fields private readonly
• Add comment explaining Windows #if in test

📋 Expand PR Finalization Review

The changes suggested in the AI summary do not work because checking the displayed page’s TabBar visibility is not valid in this scenario. If the TabBar visibility of a non-displayed page is changed dynamically, this approach breaks the expected behavior.

[MauiBot]

🚦 Gate — Test Verification

📊 Expand Full Gate — ca4a3b6 · added ios26 snaps.

---

Gate Result: ✅ PASSED

Platform: ANDROID · Base: main · Merge base: 720a9d4a

Test	Without Fix (expect FAIL)	With Fix (expect PASS)
🖥️ Issue32994 Issue32994	✅ FAIL — 1614s	✅ PASS — 527s

🔴 Without fix — 🖥️ Issue32994: FAIL ✅ · 1614s

(truncated to last 15,000 chars)

ecutionContext, ContextCallback callback, Object state) [/home/vsts/work/1/s/src/Controls/tests/TestCases.HostApp/Controls.TestCases.HostApp.csproj::TargetFramework=net10.0-android]
/home/vsts/work/1/s/.dotnet/packs/Microsoft.Android.Sdk.Linux/36.1.2/tools/Xamarin.Android.Common.Debugging.targets(333,5): error ADB0010:    at System.Threading.Tasks.Task.ExecuteWithThreadLocal(Task& currentTaskSlot, Thread threadPoolThread) [/home/vsts/work/1/s/src/Controls/tests/TestCases.HostApp/Controls.TestCases.HostApp.csproj::TargetFramework=net10.0-android]
/home/vsts/work/1/s/.dotnet/packs/Microsoft.Android.Sdk.Linux/36.1.2/tools/Xamarin.Android.Common.Debugging.targets(333,5): error ADB0010: --- End of stack trace from previous location --- [/home/vsts/work/1/s/src/Controls/tests/TestCases.HostApp/Controls.TestCases.HostApp.csproj::TargetFramework=net10.0-android]
/home/vsts/work/1/s/.dotnet/packs/Microsoft.Android.Sdk.Linux/36.1.2/tools/Xamarin.Android.Common.Debugging.targets(333,5): error ADB0010:    at AndroidDeviceExtensions.PushAndInstallPackageAsync(AndroidDevice device, PushAndInstallCommand command, CancellationToken token) [/home/vsts/work/1/s/src/Controls/tests/TestCases.HostApp/Controls.TestCases.HostApp.csproj::TargetFramework=net10.0-android]
/home/vsts/work/1/s/.dotnet/packs/Microsoft.Android.Sdk.Linux/36.1.2/tools/Xamarin.Android.Common.Debugging.targets(333,5): error ADB0010:    at AndroidDeviceExtensions.PushAndInstallPackageAsync(AndroidDevice device, PushAndInstallCommand command, CancellationToken token) [/home/vsts/work/1/s/src/Controls/tests/TestCases.HostApp/Controls.TestCases.HostApp.csproj::TargetFramework=net10.0-android]
/home/vsts/work/1/s/.dotnet/packs/Microsoft.Android.Sdk.Linux/36.1.2/tools/Xamarin.Android.Common.Debugging.targets(333,5): error ADB0010:    at Xamarin.Android.Tasks.FastDeploy.InstallPackage(Boolean installed) [/home/vsts/work/1/s/src/Controls/tests/TestCases.HostApp/Controls.TestCases.HostApp.csproj::TargetFramework=net10.0-android]
/home/vsts/work/1/s/.dotnet/packs/Microsoft.Android.Sdk.Linux/36.1.2/tools/Xamarin.Android.Common.Debugging.targets(333,5): error ADB0010:    at Xamarin.Android.Tasks.FastDeploy.InstallPackage(Boolean installed) [/home/vsts/work/1/s/src/Controls/tests/TestCases.HostApp/Controls.TestCases.HostApp.csproj::TargetFramework=net10.0-android]
/home/vsts/work/1/s/.dotnet/packs/Microsoft.Android.Sdk.Linux/36.1.2/tools/Xamarin.Android.Common.Debugging.targets(333,5): error ADB0010:    at Xamarin.Android.Tasks.FastDeploy.RunInstall() [/home/vsts/work/1/s/src/Controls/tests/TestCases.HostApp/Controls.TestCases.HostApp.csproj::TargetFramework=net10.0-android]
    0 Warning(s)
    1 Error(s)

Time Elapsed 00:15:27.84
* daemon not running; starting now at tcp:5037
* daemon started successfully
  Determining projects to restore...
  All projects are up-to-date for restore.
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13681897
  Graphics -> /home/vsts/work/1/s/artifacts/bin/Graphics/Debug/net10.0-android36.0/Microsoft.Maui.Graphics.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13681897
  Essentials -> /home/vsts/work/1/s/artifacts/bin/Essentials/Debug/net10.0-android36.0/Microsoft.Maui.Essentials.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13681897
  Core -> /home/vsts/work/1/s/artifacts/bin/Core/Debug/net10.0-android36.0/Microsoft.Maui.dll
  Controls.BindingSourceGen -> /home/vsts/work/1/s/artifacts/bin/Controls.BindingSourceGen/Debug/netstandard2.0/Microsoft.Maui.Controls.BindingSourceGen.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13681897
  Maps -> /home/vsts/work/1/s/artifacts/bin/Maps/Debug/net10.0-android36.0/Microsoft.Maui.Maps.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13681897
  Controls.Core -> /home/vsts/work/1/s/artifacts/bin/Controls.Core/Debug/net10.0-android36.0/Microsoft.Maui.Controls.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13681897
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13681897
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13681897
  Microsoft.AspNetCore.Components.WebView.Maui -> /home/vsts/work/1/s/artifacts/bin/Microsoft.AspNetCore.Components.WebView.Maui/Debug/net10.0-android36.0/Microsoft.AspNetCore.Components.WebView.Maui.dll
  Controls.Foldable -> /home/vsts/work/1/s/artifacts/bin/Controls.Foldable/Debug/net10.0-android36.0/Microsoft.Maui.Controls.Foldable.dll
  Controls.Xaml -> /home/vsts/work/1/s/artifacts/bin/Controls.Xaml/Debug/net10.0-android36.0/Microsoft.Maui.Controls.Xaml.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13681897
  Controls.Maps -> /home/vsts/work/1/s/artifacts/bin/Controls.Maps/Debug/net10.0-android36.0/Microsoft.Maui.Controls.Maps.dll
  Controls.TestCases.HostApp -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Controls.TestCases.HostApp.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13681897
  Graphics -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Microsoft.Maui.Graphics.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13681897
  Essentials -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Microsoft.Maui.Essentials.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13681897
  Core -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Microsoft.Maui.dll
  Controls.BindingSourceGen -> /home/vsts/work/1/s/artifacts/bin/Controls.BindingSourceGen/Debug/netstandard2.0/Microsoft.Maui.Controls.BindingSourceGen.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13681897
  Maps -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Microsoft.Maui.Maps.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13681897
  Controls.Core -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Microsoft.Maui.Controls.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13681897
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13681897
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13681897
  Controls.Foldable -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Microsoft.Maui.Controls.Foldable.dll
  Microsoft.AspNetCore.Components.WebView.Maui -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Microsoft.AspNetCore.Components.WebView.Maui.dll
  Controls.Xaml -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Microsoft.Maui.Controls.Xaml.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13681897
  Controls.Maps -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Microsoft.Maui.Controls.Maps.dll

Build succeeded.
    0 Warning(s)
    0 Error(s)

Time Elapsed 00:08:07.49
Broadcasting: Intent { act=android.intent.action.CLOSE_SYSTEM_DIALOGS flg=0x400000 }
Broadcast completed: result=0
Broadcasting: Intent { act=android.intent.action.CLOSE_SYSTEM_DIALOGS flg=0x400000 }
Broadcast completed: result=0
  Determining projects to restore...
  Restored /home/vsts/work/1/s/src/TestUtils/src/VisualTestUtils/VisualTestUtils.csproj (in 1.4 sec).
  Restored /home/vsts/work/1/s/src/TestUtils/src/UITest.NUnit/UITest.NUnit.csproj (in 1.34 sec).
  Restored /home/vsts/work/1/s/src/TestUtils/src/UITest.Core/UITest.Core.csproj (in 5 ms).
  Restored /home/vsts/work/1/s/src/TestUtils/src/UITest.Appium/UITest.Appium.csproj (in 1.02 sec).
  Restored /home/vsts/work/1/s/src/TestUtils/src/VisualTestUtils.MagickNet/VisualTestUtils.MagickNet.csproj (in 4.69 sec).
  Restored /home/vsts/work/1/s/src/TestUtils/src/UITest.Analyzers/UITest.Analyzers.csproj (in 2.33 sec).
  Restored /home/vsts/work/1/s/src/Controls/tests/CustomAttributes/Controls.CustomAttributes.csproj (in 4 ms).
  Restored /home/vsts/work/1/s/src/Controls/tests/TestCases.Android.Tests/Controls.TestCases.Android.Tests.csproj (in 2.31 sec).
  5 of 13 projects are up-to-date for restore.
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13681897
  Graphics -> /home/vsts/work/1/s/artifacts/bin/Graphics/Debug/net10.0/Microsoft.Maui.Graphics.dll
  Controls.CustomAttributes -> /home/vsts/work/1/s/artifacts/bin/Controls.CustomAttributes/Debug/net10.0/Controls.CustomAttributes.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13681897
  Essentials -> /home/vsts/work/1/s/artifacts/bin/Essentials/Debug/net10.0/Microsoft.Maui.Essentials.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13681897
  Core -> /home/vsts/work/1/s/artifacts/bin/Core/Debug/net10.0/Microsoft.Maui.dll
  Controls.BindingSourceGen -> /home/vsts/work/1/s/artifacts/bin/Controls.BindingSourceGen/Debug/netstandard2.0/Microsoft.Maui.Controls.BindingSourceGen.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13681897
  Controls.Core -> /home/vsts/work/1/s/artifacts/bin/Controls.Core/Debug/net10.0/Microsoft.Maui.Controls.dll
  UITest.Core -> /home/vsts/work/1/s/artifacts/bin/UITest.Core/Debug/net10.0/UITest.Core.dll
  UITest.Appium -> /home/vsts/work/1/s/artifacts/bin/UITest.Appium/Debug/net10.0/UITest.Appium.dll
  UITest.NUnit -> /home/vsts/work/1/s/artifacts/bin/UITest.NUnit/Debug/net10.0/UITest.NUnit.dll
  VisualTestUtils -> /home/vsts/work/1/s/artifacts/bin/VisualTestUtils/Debug/netstandard2.0/VisualTestUtils.dll
  VisualTestUtils.MagickNet -> /home/vsts/work/1/s/artifacts/bin/VisualTestUtils.MagickNet/Debug/netstandard2.0/VisualTestUtils.MagickNet.dll
  UITest.Analyzers -> /home/vsts/work/1/s/artifacts/bin/UITest.Analyzers/Debug/netstandard2.0/UITest.Analyzers.dll
  Controls.TestCases.Android.Tests -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.Android.Tests/Debug/net10.0/Controls.TestCases.Android.Tests.dll
Test run for /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.Android.Tests/Debug/net10.0/Controls.TestCases.Android.Tests.dll (.NETCoreApp,Version=v10.0)
VSTest version 18.0.1 (x64)

Starting test execution, please wait...
A total of 1 test files matched the specified pattern.
/home/vsts/work/1/s/artifacts/bin/Controls.TestCases.Android.Tests/Debug/net10.0/Controls.TestCases.Android.Tests.dll
[xUnit.net 00:00:00.00] xUnit.net VSTest Adapter v2.8.2+699d445a1a (64-bit .NET 10.0.0)
[xUnit.net 00:00:00.10]   Discovering: Controls.TestCases.Android.Tests
[xUnit.net 00:00:00.31]   Discovered:  Controls.TestCases.Android.Tests
NUnit Adapter 4.5.0.0: Test execution started
Running selected tests in /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.Android.Tests/Debug/net10.0/Controls.TestCases.Android.Tests.dll
   NUnit3TestExecutor discovered 4 of 4 NUnit test cases using Current Discovery mode, Non-Explicit run
>>>>> 03/29/2026 00:46:31 FixtureSetup for Issue32994(Android)
>>>>> 03/29/2026 00:46:33 TabBarVisibilityHidesOnPage1UsingDirectSet Start
>>>>> 03/29/2026 00:46:39 TabBarVisibilityHidesOnPage1UsingDirectSet Stop
>>>>> 03/29/2026 00:46:39 Log types: logcat, bugreport, server
  Failed TabBarVisibilityHidesOnPage1UsingDirectSet [6 s]
  Error Message:
   VisualTestUtils.VisualTestFailedException : 
Snapshot different than baseline: TabBarVisibilityHidesOnPage1UsingDirectSet.png (0.96% difference)
If the correct baseline has changed (this isn't a a bug), then update the baseline image.
See test attachment or download the build artifacts to get the new snapshot file.

More info: https://aka.ms/visual-test-workflow

  Stack Trace:
     at VisualTestUtils.VisualRegressionTester.Fail(String message) in /_/src/TestUtils/src/VisualTestUtils/VisualRegressionTester.cs:line 162
   at VisualTestUtils.VisualRegressionTester.VerifyMatchesSnapshot(String name, ImageSnapshot actualImage, String environmentName, ITestContext testContext) in /_/src/TestUtils/src/VisualTestUtils/VisualRegressionTester.cs:line 123
   at Microsoft.Maui.TestCases.Tests.UITest.<VerifyScreenshot>g__Verify|13_0(String name, <>c__DisplayClass13_0&) in /_/src/Controls/tests/TestCases.Shared.Tests/UITest.cs:line 477
   at Microsoft.Maui.TestCases.Tests.UITest.VerifyScreenshot(String name, Nullable`1 retryDelay, Nullable`1 retryTimeout, Int32 cropLeft, Int32 cropRight, Int32 cropTop, Int32 cropBottom, Double tolerance) in /_/src/Controls/tests/TestCases.Shared.Tests/UITest.cs:line 309
   at Microsoft.Maui.TestCases.Tests.Issues.Issue32994.TabBarVisibilityHidesOnPage1UsingDirectSet() in /_/src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue32994.cs:line 21
   at System.Reflection.MethodBaseInvoker.InterpretedInvoke_Method(Object obj, IntPtr* args)
   at System.Reflection.MethodBaseInvoker.InvokeWithNoArgs(Object obj, BindingFlags invokeAttr)

>>>>> 03/29/2026 00:46:40 TabBarVisibilityShowsOnPage1UsingDirectSet Start
>>>>> 03/29/2026 00:46:41 TabBarVisibilityShowsOnPage1UsingDirectSet Stop
>>>>> 03/29/2026 00:46:41 TabBarVisibilityShowsOnPage2UsingBinding Start
  Passed TabBarVisibilityShowsOnPage1UsingDirectSet [1 s]
>>>>> 03/29/2026 00:46:44 TabBarVisibilityShowsOnPage2UsingBinding Stop
  Passed TabBarVisibilityShowsOnPage2UsingBinding [2 s]
>>>>> 03/29/2026 00:46:44 TabBarVisibilityHidesOnPage2UsingBinding Start
>>>>> 03/29/2026 00:46:49 TabBarVisibilityHidesOnPage2UsingBinding Stop
>>>>> 03/29/2026 00:46:49 Log types: logcat, bugreport, server
  Failed TabBarVisibilityHidesOnPage2UsingBinding [5 s]
  Error Message:
   VisualTestUtils.VisualTestFailedException : 
Snapshot different than baseline: TabBarVisibilityHidesOnPage2UsingBinding.png (0.95% difference)
If the correct baseline has changed (this isn't a a bug), then update the baseline image.
See test attachment or download the build artifacts to get the new snapshot file.

More info: https://aka.ms/visual-test-workflow

  Stack Trace:
     at VisualTestUtils.VisualRegressionTester.Fail(String message) in /_/src/TestUtils/src/VisualTestUtils/VisualRegressionTester.cs:line 162
   at VisualTestUtils.VisualRegressionTester.VerifyMatchesSnapshot(String name, ImageSnapshot actualImage, String environmentName, ITestContext testContext) in /_/src/TestUtils/src/VisualTestUtils/VisualRegressionTester.cs:line 123
   at Microsoft.Maui.TestCases.Tests.UITest.<VerifyScreenshot>g__Verify|13_0(String name, <>c__DisplayClass13_0&) in /_/src/Controls/tests/TestCases.Shared.Tests/UITest.cs:line 477
   at Microsoft.Maui.TestCases.Tests.UITest.VerifyScreenshot(String name, Nullable`1 retryDelay, Nullable`1 retryTimeout, Int32 cropLeft, Int32 cropRight, Int32 cropTop, Int32 cropBottom, Double tolerance) in /_/src/Controls/tests/TestCases.Shared.Tests/UITest.cs:line 309
   at Microsoft.Maui.TestCases.Tests.Issues.Issue32994.TabBarVisibilityHidesOnPage2UsingBinding() in /_/src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue32994.cs:line 73
   at System.Reflection.MethodBaseInvoker.InterpretedInvoke_Method(Object obj, IntPtr* args)
   at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)

NUnit Adapter 4.5.0.0: Test execution complete

Total tests: 4
     Passed: 2
     Failed: 2
Test Run Failed.
 Total time: 37.0531 Seconds

🟢 With fix — 🖥️ Issue32994: PASS ✅ · 527s

  Determining projects to restore...
  All projects are up-to-date for restore.
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13681897
  Graphics -> /home/vsts/work/1/s/artifacts/bin/Graphics/Debug/net10.0-android36.0/Microsoft.Maui.Graphics.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13681897
  Essentials -> /home/vsts/work/1/s/artifacts/bin/Essentials/Debug/net10.0-android36.0/Microsoft.Maui.Essentials.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13681897
  Core -> /home/vsts/work/1/s/artifacts/bin/Core/Debug/net10.0-android36.0/Microsoft.Maui.dll
  Controls.BindingSourceGen -> /home/vsts/work/1/s/artifacts/bin/Controls.BindingSourceGen/Debug/netstandard2.0/Microsoft.Maui.Controls.BindingSourceGen.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13681897
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13681897
  Maps -> /home/vsts/work/1/s/artifacts/bin/Maps/Debug/net10.0-android36.0/Microsoft.Maui.Maps.dll
  Controls.Core -> /home/vsts/work/1/s/artifacts/bin/Controls.Core/Debug/net10.0-android36.0/Microsoft.Maui.Controls.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13681897
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13681897
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13681897
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13681897
  Controls.Foldable -> /home/vsts/work/1/s/artifacts/bin/Controls.Foldable/Debug/net10.0-android36.0/Microsoft.Maui.Controls.Foldable.dll
  Controls.Maps -> /home/vsts/work/1/s/artifacts/bin/Controls.Maps/Debug/net10.0-android36.0/Microsoft.Maui.Controls.Maps.dll
  Controls.Xaml -> /home/vsts/work/1/s/artifacts/bin/Controls.Xaml/Debug/net10.0-android36.0/Microsoft.Maui.Controls.Xaml.dll
  Microsoft.AspNetCore.Components.WebView.Maui -> /home/vsts/work/1/s/artifacts/bin/Microsoft.AspNetCore.Components.WebView.Maui/Debug/net10.0-android36.0/Microsoft.AspNetCore.Components.WebView.Maui.dll
  Controls.TestCases.HostApp -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Controls.TestCases.HostApp.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13681897
  Graphics -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Microsoft.Maui.Graphics.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13681897
  Essentials -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Microsoft.Maui.Essentials.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13681897
  Core -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Microsoft.Maui.dll
  Controls.BindingSourceGen -> /home/vsts/work/1/s/artifacts/bin/Controls.BindingSourceGen/Debug/netstandard2.0/Microsoft.Maui.Controls.BindingSourceGen.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13681897
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13681897
  Maps -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Microsoft.Maui.Maps.dll
  Controls.Core -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Microsoft.Maui.Controls.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13681897
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13681897
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13681897
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13681897
  Controls.Foldable -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Microsoft.Maui.Controls.Foldable.dll
  Controls.Maps -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Microsoft.Maui.Controls.Maps.dll
  Microsoft.AspNetCore.Components.WebView.Maui -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Microsoft.AspNetCore.Components.WebView.Maui.dll
  Controls.Xaml -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Microsoft.Maui.Controls.Xaml.dll

Build succeeded.
    0 Warning(s)
    0 Error(s)

Time Elapsed 00:06:33.00
Broadcasting: Intent { act=android.intent.action.CLOSE_SYSTEM_DIALOGS flg=0x400000 }
Broadcast completed: result=0
Broadcasting: Intent { act=android.intent.action.CLOSE_SYSTEM_DIALOGS flg=0x400000 }
Broadcast completed: result=0
  Determining projects to restore...
  All projects are up-to-date for restore.
  Controls.CustomAttributes -> /home/vsts/work/1/s/artifacts/bin/Controls.CustomAttributes/Debug/net10.0/Controls.CustomAttributes.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13681897
  Graphics -> /home/vsts/work/1/s/artifacts/bin/Graphics/Debug/net10.0/Microsoft.Maui.Graphics.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13681897
  Essentials -> /home/vsts/work/1/s/artifacts/bin/Essentials/Debug/net10.0/Microsoft.Maui.Essentials.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13681897
  Core -> /home/vsts/work/1/s/artifacts/bin/Core/Debug/net10.0/Microsoft.Maui.dll
  Controls.BindingSourceGen -> /home/vsts/work/1/s/artifacts/bin/Controls.BindingSourceGen/Debug/netstandard2.0/Microsoft.Maui.Controls.BindingSourceGen.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13681897
  Controls.Core -> /home/vsts/work/1/s/artifacts/bin/Controls.Core/Debug/net10.0/Microsoft.Maui.Controls.dll
  VisualTestUtils -> /home/vsts/work/1/s/artifacts/bin/VisualTestUtils/Debug/netstandard2.0/VisualTestUtils.dll
  UITest.Core -> /home/vsts/work/1/s/artifacts/bin/UITest.Core/Debug/net10.0/UITest.Core.dll
  UITest.Appium -> /home/vsts/work/1/s/artifacts/bin/UITest.Appium/Debug/net10.0/UITest.Appium.dll
  UITest.NUnit -> /home/vsts/work/1/s/artifacts/bin/UITest.NUnit/Debug/net10.0/UITest.NUnit.dll
  VisualTestUtils.MagickNet -> /home/vsts/work/1/s/artifacts/bin/VisualTestUtils.MagickNet/Debug/netstandard2.0/VisualTestUtils.MagickNet.dll
  UITest.Analyzers -> /home/vsts/work/1/s/artifacts/bin/UITest.Analyzers/Debug/netstandard2.0/UITest.Analyzers.dll
  Controls.TestCases.Android.Tests -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.Android.Tests/Debug/net10.0/Controls.TestCases.Android.Tests.dll
Test run for /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.Android.Tests/Debug/net10.0/Controls.TestCases.Android.Tests.dll (.NETCoreApp,Version=v10.0)
VSTest version 18.0.1 (x64)

Starting test execution, please wait...
A total of 1 test files matched the specified pattern.
/home/vsts/work/1/s/artifacts/bin/Controls.TestCases.Android.Tests/Debug/net10.0/Controls.TestCases.Android.Tests.dll
[xUnit.net 00:00:00.00] xUnit.net VSTest Adapter v2.8.2+699d445a1a (64-bit .NET 10.0.0)
[xUnit.net 00:00:00.10]   Discovering: Controls.TestCases.Android.Tests
[xUnit.net 00:00:00.28]   Discovered:  Controls.TestCases.Android.Tests
NUnit Adapter 4.5.0.0: Test execution started
Running selected tests in /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.Android.Tests/Debug/net10.0/Controls.TestCases.Android.Tests.dll
   NUnit3TestExecutor discovered 4 of 4 NUnit test cases using Current Discovery mode, Non-Explicit run
>>>>> 03/29/2026 00:55:29 FixtureSetup for Issue32994(Android)
>>>>> 03/29/2026 00:55:32 TabBarVisibilityHidesOnPage1UsingDirectSet Start
>>>>> 03/29/2026 00:55:36 TabBarVisibilityHidesOnPage1UsingDirectSet Stop
  Passed TabBarVisibilityHidesOnPage1UsingDirectSet [3 s]
>>>>> 03/29/2026 00:55:36 TabBarVisibilityShowsOnPage1UsingDirectSet Start
>>>>> 03/29/2026 00:55:37 TabBarVisibilityShowsOnPage1UsingDirectSet Stop
>>>>> 03/29/2026 00:55:37 TabBarVisibilityShowsOnPage2UsingBinding Start
  Passed TabBarVisibilityShowsOnPage1UsingDirectSet [1 s]
>>>>> 03/29/2026 00:55:39 TabBarVisibilityShowsOnPage2UsingBinding Stop
  Passed TabBarVisibilityShowsOnPage2UsingBinding [2 s]
>>>>> 03/29/2026 00:55:39 TabBarVisibilityHidesOnPage2UsingBinding Start
>>>>> 03/29/2026 00:55:43 TabBarVisibilityHidesOnPage2UsingBinding Stop
  Passed TabBarVisibilityHidesOnPage2UsingBinding [3 s]
NUnit Adapter 4.5.0.0: Test execution complete

Test Run Successful.
Total tests: 4
     Passed: 4
 Total time: 26.0589 Seconds

📁 Fix files reverted (3 files)

• eng/pipelines/ci-copilot.yml
• src/Controls/src/Core/Shell/ShellElementCollection.cs
• src/Controls/src/Core/Shell/ShellItem.cs

---

[MauiBot]

🤖 AI Summary

📊 Expand Full Review — ca4a3b6 · added ios26 snaps.

---

🔍 Pre-Flight — Context & Validation

---

Issue: #32994 - Shell.TabBarIsVisible is not updated dynamically at runtime
PR: #33090 - Fix TabBarIsVisible Not Updating Dynamically When Set on ShellContent
Author: Vignesh-SF3580 (community contributor, Syncfusion partner)
Platforms Affected: iOS, Android, Windows, MacCatalyst
Files Changed: 2 implementation, 2 test + 8 snapshot images

Key Findings

• Shell.TabBarIsVisible set on ShellContent (directly or via binding) was silently ignored because ShellContent is not in the ancestor chain of displayedPage when GetEffectiveValue walks up.
• ShowTabs in ShellItem always started from displayedPage which has parent chain: Page → ShellSection → ShellItem → Shell — never passing through ShellContent.
• PR adds two fixes: (1) ShellItem.ShowTabs now starts from shellContent when it has TabBarIsVisible set; (2) ShellElementCollection.BaseShellItemPropertyChanged syncs ShellContent value to displayed page via Shell.SetTabBarIsVisible(displayedPage, ...).
• Precedence concern (from copilot reviewer): PR's ShowTabs fix checks shellContent.IsSet() first. If true, uses shellContent as starting element — which skips displayedPage. This means if a page also has TabBarIsVisible set, it would be overridden by ShellContent's value. The correct precedence should be: Page > ShellContent > ShellSection > ShellItem > Shell.
• Mutation concern (from copilot reviewer): Shell.SetTabBarIsVisible(displayedPage, shellContentValue) sets a local value on the page's attached property, potentially overriding page-specific settings.
• Prior agent review (from rmarinho comment) ran 1 of 4 models (sonnet-4.6) and requested changes due to the precedence issue. The PR author responded that the handler-based approach fails and checking displayedPage.IsSet() first would break non-displayed page scenarios.
• Gate PASSED on Android - all 4 tests pass with fix, fail without fix.
• All prior inline reviewer comments (5) have been resolved by the PR author.

Fix Candidates

#	Source	Approach	Test Result	Files Changed	Notes
PR	PR #33090	Use shellContent as starting element when shellContent.IsSet(TabBarIsVisible) + sync to page via Shell.SetTabBarIsVisible(displayedPage)	✅ PASSED (Gate)	ShellItem.cs, ShellElementCollection.cs	Original PR; precedence concern: page value can be overridden by ShellContent

---

🔧 Fix — Analysis & Comparison

---

Fix Candidates

#	Source	Approach	Test Result	Files Changed	Notes
1	try-fix (claude-opus-4.6)	Explicit Page > ShellContent precedence check in ShowTabs + shell.CurrentItem.Handler.UpdateValue() for dynamic updates (no page mutation)	✅ PASS	ShellItem.cs, ShellElementCollection.cs	Cleaner precedence; avoids mutating displayedPage state
2	try-fix (claude-sonnet-4.6)	propertyChanged callback on TabBarIsVisibleProperty in Shell.cs propagates to ContentCache page; ShowTabs explicit precedence (Page → ShellContent → GetEffectiveValue from CurrentItem)	✅ PASS	ShellItem.cs, Shell.cs	More invasive (modifies property registration); different starting element for GetEffectiveValue
3	try-fix (gpt-5.3-codex)	ShellItem-only: manual precedence walk + ShellItem-owned PropertyChanged subscription for refresh	❌ FAIL	ShellItem.cs	AppearanceChanged/UpdateValue alone insufficient on Android; ShellItem.Handler may be null
4	try-fix (gpt-5.4)	Explicit Page > ShellContent precedence + guarded sync (skip sync if page already has value set)	❌ FAIL	ShellItem.cs, ShellElementCollection.cs	Guard displayedPage.IsSet() blocks subsequent updates after first sync
PR	PR #33090	ShowTabs: use shellContent as start when shellContent.IsSet() (bypasses displayedPage); ShellElementCollection: sync to page via Shell.SetTabBarIsVisible(displayedPage, ...)	✅ PASS (Gate)	ShellItem.cs, ShellElementCollection.cs	Precedence concern: page value bypassed when shellContent has value set

Cross-Pollination

Model	Round	New Ideas?	Details
claude-opus-4.6	2	Yes	Override OnTabBarIsVisibleChanged in ShellContent to call InvalidateMeasureNonVirtual on parent ShellSection — speculative, not tested
claude-sonnet-4.6	2	Yes	Add propertyChanged callback on TabBarIsVisibleProperty calling shellItem.Handler.UpdateValue() — essentially Attempt 2 variant, but Handler.UpdateValue alone proved insufficient in Attempt 3

Exhausted: Yes — all 4 models queried, no new viable distinct approaches identified
Selected Fix: PR's fix (with recommended precedence fix) — PR's fix passes Gate and tests; Attempt 1 demonstrates the precedence fix (check displayedPage.IsSet() first) is feasible and passes the same tests. The PR should update ShowTabs to check displayedPage.IsSet() before checking shellContent.IsSet().

---

📋 Report — Final Recommendation

---

⚠️ Final Recommendation: REQUEST CHANGES

Phase Status

Phase	Status	Notes
Pre-Flight	✅ COMPLETE	Issue #32994, Shell.TabBarIsVisible on ShellContent ignored
Gate	✅ PASSED	Android — tests fail without fix, pass with fix
Try-Fix	✅ COMPLETE	4 attempts: 2 pass (Attempt 1, 2), 2 fail (Attempt 3, 4)
Report	✅ COMPLETE

Summary

PR #33090 fixes a real, verified bug where Shell.TabBarIsVisible set on ShellContent (directly or via binding) was silently ignored at runtime. The fix is functionally correct and passes all tests. However, the ShowTabs change in ShellItem.cs has a precedence inversion that could cause a regression in edge cases where a page overrides a ShellContent value.

One specific change is needed before this can be approved.

Root Cause

ShellContent is not in the ancestor chain of displayedPage. The GetEffectiveValue walk starts at Page and walks up: Page → ShellSection → ShellItem → Shell — never passing through ShellContent. So values set on ShellContent were always silently skipped.

Fix Quality

What's good:

• Both fix sites (ShellItem.ShowTabs and ShellElementCollection.BaseShellItemPropertyChanged) address the root cause
• Test coverage is solid — 4 UI tests covering direct set and binding scenarios on Page1 and Page2
• All prior inline reviewer comments (5) have been addressed by the author
• Gate PASSED on Android

The issue — precedence inversion in ShellItem.cs line 144:

// PR's current code (PROBLEMATIC):
var shellContent = CurrentItem?.CurrentItem;
if (shellContent is not null && shellContent.IsSet(Shell.TabBarIsVisibleProperty))
{
    currentPage = shellContent;  // ← bypasses displayedPage entirely
}
return shell.GetEffectiveValue<bool>(..., currentPage);

When shellContent.IsSet() is true, the walk starts from shellContent, completely skipping displayedPage. This means if a developer explicitly calls Shell.SetTabBarIsVisible(displayedPage, true) to override a ShellContent-level false, the page override is silently ignored. The correct precedence should be: Page > ShellContent > ShellSection > ShellItem > Shell.

Try-Fix verified fix (Attempt 1 — ✅ PASS):

// Correct precedence:
if (displayedPage is not null && displayedPage.IsSet(Shell.TabBarIsVisibleProperty))
    return (bool)displayedPage.GetValue(Shell.TabBarIsVisibleProperty);

var shellContent = CurrentItem?.CurrentItem;
if (shellContent is not null && shellContent.IsSet(Shell.TabBarIsVisibleProperty))
    return (bool)shellContent.GetValue(Shell.TabBarIsVisibleProperty);

// Fall through to ancestor walk (ShellSection > ShellItem > Shell)
return shell.GetEffectiveValue<bool>(Shell.TabBarIsVisibleProperty, () => defaultShowTabs, null, displayedPage);

Attempt 1 also avoids mutating displayedPage's state in ShellElementCollection — using shell.CurrentItem.Handler.UpdateValue(...) instead. However, Attempt 2 found that on Android, ShellItem.Handler may be null, so the dynamic update path via handler invalidation may be unreliable. The PR's Shell.SetTabBarIsVisible(displayedPage, ...) approach is the more reliable dynamic update mechanism for Android.

Recommended change:
Update ShellItem.ShowTabs to check displayedPage.IsSet() FIRST (before checking shellContent.IsSet()), as shown in the Attempt 1 diff above. The ShellElementCollection change can remain as-is — it correctly syncs the value and only acts when the displayed page belongs to the changed ShellContent.

Selected Fix: PR (with required precedence fix)

---

[kubaflo]

Could you please review the AI's summary?

[Vignesh-SF3580]

Could you please review the AI's summary?

@kubaflo As I mentioned earlier, the changes suggested in the AI summary do not work because checking the displayed page’s TabBar visibility is not valid in this scenario. If the TabBar visibility of a non-displayed page is changed dynamically, this approach breaks the expected behavior.