[Android] Fix control size properties not available during Loaded event

[Vignesh-SF3580]

Note

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

Issue Details

On Android, controls do not provide valid size when the Loaded event fires.



Root Cause

On Android, the Loaded event fires before the layout pass completes, causing views to report incorrect dimensions.

Description of Change

Modified OnLoaded method to use view.Post() instead of immediate action execution, ensuring the Loaded event fires after the layout pass completes.

Tested the behavior in the following platforms

• Android
• Windows
• iOS
• Mac

Issues Fixed

Fixes #14364
Fixes #14160

Screenshots

Before Issue Fix	After Issue Fix

[dotnet-policy-service]

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

[jsuarezruiz]

/azp run MAUI-UITests-public

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[Copilot]

Pull Request Overview

This PR fixes an Android-specific issue where control size properties (Height and Width) were not available during the Loaded event because the event fired before the layout pass completed.

• Modified the OnLoaded method to use view.Post() to defer action execution until after layout completion
• Added comprehensive UI tests to validate the fix works correctly
• Ensures size properties are properly available when Loaded event handlers execute

Reviewed Changes

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

File	Description
src/Core/src/Platform/Android/ViewExtensions.cs	Changed immediate action execution to deferred execution using view.Post()
src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue14364.cs	Added NUnit test to verify size properties are available during Loaded event
src/Controls/tests/TestCases.HostApp/Issues/Issue14364.cs	Added test page with Grid and Label to reproduce and validate the issue fix

[jsuarezruiz]

/rebase

[jsuarezruiz]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[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://github.com/dotnet/maui/main/eng/scripts/get-maui-pr.sh | bash -s -- 31590

Or

• Run remotely in PowerShell:

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

[rmarinho]

🤖 AI Summary

📊 Expand Full Review

---

🔍 Pre-Flight — Context & Validation

---

📝 Review Session — Update ViewExtensions.cs · 58db172

---

Issue: #14364 - CollectionView on Android does not provide height/width/size during Loaded event
PR: #31590 - [Android] Fix control size properties not available during Loaded event
Platforms Affected: Android only (platform/android label)
Files Changed: 1 implementation file, 2 test files
Author: Vignesh-SF3580 (Syncfusion partner, community contribution)
Current Commit: 58db172
Prior Agent Reviews: Yes - prior reviews on older commits (bddc900); labels s/agent-reviewed, s/agent-approved, s/agent-fix-pr-picked already applied

Issue Summary

On Android, the Loaded event fires before the layout pass completes, causing controls (Labels, CollectionViews, etc.) to report incorrect dimensions (Height: -1, Width: -1). This works correctly on Windows and iOS where the layout pass completes before Loaded fires. Issues #14364 and #14160 both describe the same root cause.

Fix Approach (Current Commit: 58db172)

In src/Core/src/Platform/Android/ViewExtensions.cs, the OnLoaded method's ViewAttachedToWindow event handler now uses view.Post() to defer execution to after the current layout pass. Key improvements over prior commits:

• localDisposable captures reference before nulling field, preventing race conditions
• Disposal happens INSIDE the Post callback, AFTER calling action() (correct lifecycle)
• IsAttachedToWindow guard prevents action from firing if view was detached
• localDisposable is not null guard prevents double-execution

Current code:

var localDisposable = disposable;
disposable = null;
view.Post(() =>
{
    if (view.IsAttachedToWindow && localDisposable is not null)
    {
        action();
        localDisposable.Dispose();
    }
});

PR Discussion Summary

• jsuarezruiz (reviewer) requested changes: add IsAttachedToWindow guard since action runs asynchronously
• Author updated code, adding localDisposable pattern + IsAttachedToWindow check
• copilot-pull-request-reviewer found no issues with changed files
• Prior agent reviews (on bddc900) confirmed Gate PASSED and recommended APPROVE

Key Reviewer Feedback

File:Line	Reviewer	Feedback	Status
ViewExtensions.cs:583	jsuarezruiz	Add IsAttachedToWindow guard inside Post callback	✅ Implemented

Edge Cases

• View detached between ViewAttachedToWindow and Post() — handled by IsAttachedToWindow check
• Disposal race — mitigated by localDisposable pattern (local reference before nulling field)
• Action called after disposal — prevented by localDisposable is not null check + disposal after action()
• Loaded fires twice — guarded by localDisposable is not null

Fix Candidates

#	Source	Approach	Test Result	Files Changed	Notes
PR	PR #31590	view.Post() with IsAttachedToWindow + localDisposable pattern	⏳ PENDING (Gate)	ViewExtensions.cs (+10/-2)	Current commit 58db172

---

🚦 Gate — Test Verification

---

📝 Review Session — Update ViewExtensions.cs · 58db172

---

Result: ✅ PASSED
Platform: android
Mode: Full Verification

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

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

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

Platform Note: Android is the affected platform per the platform/android label and the fix in Platform/Android/ViewExtensions.cs. Testing on an unaffected platform would yield false positives.

---

🔧 Fix — Analysis & Comparison

---

📝 Review Session — Update ViewExtensions.cs · 58db172

---

Fix Candidates

#	Source	Approach	Test Result	Files Changed	Notes
PR	PR #31590	view.Post() with IsAttachedToWindow + localDisposable	✅ PASS (Gate)	1 file (+10/-2)	Simplest, most idiomatic Android pattern
1	try-fix (claude-sonnet-4.6)	ViewTreeObserver.IOnGlobalLayoutListener	✅ PASS	1 file (+71/-2)	Works but fires tree-wide, adds helper class
2	try-fix (claude-opus-4.6)	view.LayoutChange event (per-view listener)	✅ PASS	1 file (+14/-2)	Works, semantically precise, but adds event subscription complexity
3	try-fix (gpt-5.2)	Choreographer.IFrameCallback with IsLaidOut/dimension polling	✅ PASS	1 file (large)	Works but significantly more complex, adds polling class
4	try-fix (gpt-5.3-codex)	Handler(Looper.MainLooper) + PostDelayed readiness loop	✅ PASS	1 file (+45/-15)	Works but adds retry logic and timing delays
5	try-fix (gemini-3-pro-preview)	ViewTreeObserver.IOnPreDrawListener	✅ PASS	1 file (+35/-17)	Works but adds helper class, fires before every draw

Cross-Pollination Summary

Round	Model	Response
2	claude-sonnet-4.6	NO NEW IDEAS
2	claude-opus-4.6	NO NEW IDEAS
2	gpt-5.2	NO NEW IDEAS
2	gpt-5.3-codex	NO NEW IDEAS
2	gemini-3-pro-preview	NO NEW IDEAS

Exhausted: Yes — all 5 models confirmed no new ideas in Round 2. The fix space spans all practical Android layout-readiness mechanisms: message queue deferral, layout lifecycle callbacks, and frame pipeline hooks.

Selected Fix: PR's fix — view.Post() with IsAttachedToWindow guard and localDisposable pattern. All 5 alternatives also pass, but the PR's approach is:

• Fewest lines changed (+10/-2 vs +14 to +71 for alternatives)
• Most idiomatic Android pattern (view.Post() is the canonical deferral mechanism)
• No helper classes needed
• Easiest to understand and maintain

---

📋 Report — Final Recommendation

---

📝 Review Session — Update ViewExtensions.cs · 58db172

---

✅ Final Recommendation: APPROVE

---

PR Finalize Analysis

✅ Title: Good — No Change Needed

Current: [Android] Fix control size properties not available during Loaded event

The title is accurate, has the correct platform prefix, describes the behavior being fixed, and is searchable. No change recommended.

✅ Description: Good — Minor Enhancement Suggested

Quality assessment:

• NOTE block: ✅ Present at top
• Root cause: ✅ Clearly explained
• Description of change: ✅ Matches implementation (mentions view.Post())
• Issues fixed: ✅ Both CollectionView on Android does not provide height, width, logical children once loaded, works fine on Windows #14364 and Control's Loaded event invokes before calling its measure override method. #14160 linked
• Platforms tested: ✅ All platforms listed
• Screenshots: ✅ Before/after screenshots included
• Agent context: ⚠️ Missing localDisposable pattern rationale and "What NOT to Do" notes

Suggested addition to "Description of Change" section:

Key detail: view.Post() queues execution for the next Looper cycle (after the layout pass), ensuring Width and Height are valid when the Loaded handler fires. The localDisposable pattern captures the reference before nulling the field so disposal can happen correctly inside the callback, after calling action(). The IsAttachedToWindow guard prevents action from firing if the view was detached between ViewAttachedToWindow and post execution.

What NOT to Do (for future agents)

• ❌ Don't use ViewTreeObserver.IOnGlobalLayoutListener — Works but fires tree-wide after any view layout, more verbose, requires a helper class
• ❌ Don't use view.LayoutChange event — Works but adds per-view listener lifecycle complexity for the same outcome
• ❌ Don't use Choreographer.IFrameCallback — Works but significantly more complex, adds polling class with retry logic
• ❌ Don't use Handler(Looper.MainLooper) + PostDelayed — Works but introduces timing delays and retry logic (45+ lines vs 10)
• ❌ Don't use ViewTreeObserver.IOnPreDrawListener — Works but adds helper class and fires before every draw frame

---

Code Review Findings

✅ Looks Good

• Minimal change: Only 10 lines changed in the fix file — the smallest change that correctly fixes the root cause
• Idiomatic Android pattern: view.Post() is the canonical Android idiom for deferring work to after the current layout pass; confirmed by 5 independent model explorations
• localDisposable pattern is correct: Captures local reference before nulling field, disposes inside callback after calling action() — correct lifecycle ordering
• IsAttachedToWindow guard: Addresses reviewer feedback from jsuarezruiz; prevents stale action execution if view detaches between event and callback
• localDisposable is not null guard: Prevents double-execution if somehow invoked twice
• Test assertions: Is.Not.EqualTo("Height: -1, Width: -1") correctly validates the broken state without hardcoding specific pixel values (fragile)
• [Category(UITestCategories.Layout)]: Appropriate category for a layout timing test
• Both issues fixed: CollectionView on Android does not provide height, width, logical children once loaded, works fine on Windows #14364 and Control's Loaded event invokes before calling its measure override method. #14160 describe the same root cause; one fix/test covers both

🟡 Minor Observations

1. Missing newline at end of TestCases.Shared.Tests/Tests/Issues/Issue14364.cs (\ No newline at end of file in diff). Minor style issue.

2. Issue14364 HostApp extends Shell directly instead of TestShell. Per UITest guidelines TestShell is preferred for Shell tests; however this implementation is functionally correct and the custom Shell setup is minimal and clear.

3. Test asserts negative (Not.EqualTo) rather than positive dimensions. This is appropriate for a regression test — asserting the bug state is gone without fragile pixel value assertions. Optional enhancement: add Assert.That(double.Parse(...), Is.GreaterThan(0)).

🔴 No Critical Issues Found

---

Summary of Findings

Phase Completion Status

Phase	Status	Notes
✅ Pre-Flight	Complete	PR context gathered, current commit 58db172 reviewed
✅ Gate	PASSED	Tests FAIL without fix, PASS with fix (Android)
✅ Fix	Complete	5 alternatives explored (all pass), PR's fix is simplest
✅ Report	Complete	This document

Fix Validation Summary

#	Source	Approach	Test Result
PR	PR #31590	view.Post() + IsAttachedToWindow + localDisposable	✅ PASS (Gate verified)
1	try-fix	ViewTreeObserver.IOnGlobalLayoutListener	✅ PASS
2	try-fix	view.LayoutChange event	✅ PASS
3	try-fix	Choreographer.IFrameCallback with dimension polling	✅ PASS
4	try-fix	Handler(Looper.MainLooper) + PostDelayed retry loop	✅ PASS
5	try-fix	ViewTreeObserver.IOnPreDrawListener	✅ PASS

Cross-pollination: Round 2 with all 5 models — unanimous "NO NEW IDEAS". Fix space exhausted.

Selected Fix: PR's fix — all 5 alternatives also pass, but view.Post() is the simplest, most idiomatic Android pattern with the fewest lines changed.

Final Recommendation

✅ APPROVE — The PR correctly fixes a real Android-specific timing bug:

• Root cause confirmed: ViewAttachedToWindow fires before the layout pass completes on Android
• Fix is correct and idiomatic: view.Post() defers to the next Looper cycle (after layout)
• Guards are appropriate: IsAttachedToWindow + localDisposable is not null
• Reviewer feedback from jsuarezruiz has been fully incorporated
• Tests properly validate the fix
• Five independently-generated alternatives all confirm the approach space is well-covered
• PR's implementation is the simplest of all valid alternatives

---

📋 Expand PR Finalization Review

---

Title: ✅ Good

Current: [Android] Fix control size properties not available during Loaded event

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!

Root Cause

On Android, the ViewAttachedToWindow event fires as soon as the view is attached to the window hierarchy, but before Android's layout pass completes. This means that at the moment the MAUI Loaded event was fired, Height, Width, DesiredSize, and LogicalChildren all reported stale/default values (e.g., -1 for dimensions).

Description of Change

Modified the routedEventHandler lambda inside OnLoaded in src/Core/src/Platform/Android/ViewExtensions.cs to defer the action via view.Post() instead of calling it immediately inline.

view.Post() enqueues work on Android's main message queue, so it runs after the current layout pass has completed. By the time the posted callback fires, all dimension properties are populated.

Key implementation detail: The existing disposable reference is captured into a localDisposable local variable before posting, then set to null. This allows the async callback to safely check whether the subscription was cancelled between the event firing and the callback running.

What changed and what didn't:

• ✅ Changed: The "normal" path in routedEventHandler — where the view becomes attached and is already considered loaded — now defers via view.Post()
• ✅ Unchanged: The "fast path" where OnLoaded is called on an already-loaded view (immediate call is still correct there; layout has already completed)
• ✅ Unchanged: The !view.IsLoaded() retry path that already used new Handler(q).Post()

What NOT to Do (for future agents)

• ❌ Don't call action() directly in ViewAttachedToWindow — Android fires this event before the layout pass completes; dimensions will be -1 or stale
• ❌ Don't skip the localDisposable pattern — Without capturing disposable locally before the async callback, setting disposable = null would race with any caller trying to cancel the subscription

Issues Fixed

Fixes #14364
Fixes #14160

Tested the behavior in the following platforms

• Android
• Windows
• iOS
• Mac

Screenshots

Before Issue Fix	After Issue Fix

Code Review: ✅ Passed

Code Review — PR #31590

File changed: src/Core/src/Platform/Android/ViewExtensions.cs
Test files added: Issue14364.cs (HostApp + SharedTests)

---

🟡 Suggestions

1. localDisposable is not disposed when view detaches before the Post callback runs

File: src/Core/src/Platform/Android/ViewExtensions.cs (lines ~644–653)

Problem: The new code sets disposable = null and enqueues a view.Post() callback. Inside that callback, if view.IsAttachedToWindow is false (the view detached between the event firing and the callback running), neither action() is called nor localDisposable.Dispose() is invoked. localDisposable.Dispose() is what unsubscribes routedEventHandler from view.ViewAttachedToWindow. As a result, the event handler remains subscribed on the view.

If the view is later re-attached, routedEventHandler will fire a second time. At that point, disposable is null (it was set to null in the first invocation), so localDisposable = disposable captures null, and the action is skipped — this prevents a double-fire. However, the handler is never cleaned up, creating a long-lived unnecessary reference.

Code (current):

var localDisposable = disposable;
disposable = null;
view.Post(() =>
{
    if (view.IsAttachedToWindow && localDisposable is not null)
    {
        action();
        localDisposable.Dispose();
    }
    // ⚠️ Missing: else { localDisposable?.Dispose(); } 
});

Recommendation: Dispose the local disposable in all code paths inside the Post callback:

var localDisposable = disposable;
disposable = null;
view.Post(() =>
{
    if (view.IsAttachedToWindow && localDisposable is not null)
    {
        action();
    }
    localDisposable?.Dispose();
});

Severity: Minor — the handler itself is lightweight and the scenario (view detaching between attach event and next looper iteration) is rare. Not a blocker.

---

2. Missing newline at end of test file

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

The diff shows \ No newline at end of file at the end of this file. Most editors and git tooling prefer a trailing newline.

Recommendation: Add a newline character at the end of the file.

Severity: Minor / style.

---

3. Test validates Label but issue #14364 reports CollectionView

File: src/Controls/tests/TestCases.HostApp/Issues/Issue14364.cs

Problem: Issue #14364 specifically reports that CollectionView height, width, and LogicalChildren are not available during Loaded. The test uses a Label inside a Grid with fixed HeightRequest/WidthRequest. While a Label is a simpler repro and exercises the same OnLoaded code path, it doesn't fully validate the CollectionView scenario. In particular, LogicalChildren.Count — which was explicitly listed as broken in the issue — is not tested.

Assessment: The core fix is in OnLoaded in ViewExtensions.cs, which is shared by all views including CollectionView. Testing with a Label does exercise the fix. This is a pragmatic tradeoff (simpler HostApp test, easier to make reliable). Not a blocker.

Recommendation (optional): Consider adding a comment in the test explaining why Label is used instead of CollectionView.

Severity: Minor / informational.

---

✅ Looks Good

• Core fix is sound: view.Post() is the correct Android idiom for deferring work to after the layout pass. This is well-established practice.
• IsAttachedToWindow guard: Adding view.IsAttachedToWindow check inside the Post callback correctly handles the race where a view is detached before the callback runs. This was recommended by reviewer jsuarezruiz and was incorporated.
• localDisposable pattern: Capturing disposable into a local before setting it to null is the right approach for allowing cancellation detection in async callbacks.
• Both issues addressed: The fix correctly addresses both CollectionView on Android does not provide height, width, logical children once loaded, works fine on Windows #14364 (control sizes not available in Loaded) and Control's Loaded event invokes before calling its measure override method. #14160 (Loaded fires before MeasureOverride).
• Cross-platform safety: The change is scoped to the Android platform file (Platform/Android/ViewExtensions.cs) and does not affect iOS/Windows/Mac paths.
• Tests added: Both a HostApp page and a SharedTests NUnit test were added, following the correct two-project pattern.
• No breaking changes: The behavioral change (slight delay in Loaded event firing) is the intended fix and aligns with user expectations.

---

[sheiksyedm]

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

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[kubaflo]

Looks like tests are failing. Could you verify if the failures are related to the changes?

[Vignesh-SF3580]

Looks like tests are failing. Could you verify if the failures are related to the changes?

@kubaflo The fix is Android-specific. I verified the failing Android UI test "LayoutShouldBeCorrectOnFirstNavigation", and it passed locally. The test failures are not related to this fix.