[Windows] Fix for MenuFlyoutItem displaying icon in monochrome instead of original colors

[SyedAbdulAzeemSF4852]

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

• MenuFlyoutItem with FileImageSource and UriImageSource displays icon in monochrome instead of original colors.

Root Cause

• The issue occurred because BitmapIconSource renders images in monochrome mode by default. As a result, the original colors from FileImageSource and UriImageSource were lost when displayed as icons.

Description of Change

• Updated MenuFlyoutItemHandler.Windows.cs to set ShowAsMonochrome = false for BitmapIconSource, ensuring icons retain their original colors instead of being rendered as monochrome silhouettes.
• Documentation : ShowAsMonoChrome

Issues Fixed

Fixes #16119

Validated the behaviour in the following platforms

• Windows
• Mac
• Android
• iOS

Output

Before	After

[sheiksyedm]

/azp run

[Copilot]

Pull Request Overview

This PR fixes a Windows-specific issue where MenuFlyoutItem icons from FileImageSource and UriImageSource were displayed in monochrome instead of their original colors. The root cause was that BitmapIconSource renders images as monochrome silhouettes by default.

Key Changes

• Updated MenuFlyoutItemHandler.Windows.cs to set ShowAsMonochrome = false for BitmapIconSource instances
• Added UI test case to verify the fix with screenshot validation

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
src/Core/src/Handlers/MenuFlyoutItem/MenuFlyoutItemHandler.Windows.cs	Modified MapSource method to disable monochrome rendering for BitmapIconSource, preserving original icon colors
src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue16119.cs	Added NUnit UI test with screenshot verification for Windows platform
src/Controls/tests/TestCases.HostApp/Issues/Issue16119.cs	Created test Shell page with MenuFlyoutItem using FileImageSource to demonstrate the fix

[kubaflo]

Could you please add screenshots?

[sheiksyedm]

/azp run maui-pr-uitests

[SyedAbdulAzeemSF4852]

Could you please add screenshots?

@kubaflo , I’ve added the baseline snapshot for the Windows platform

[kubaflo]

Looks like the test couldn't catch a bug before fix - could you please verify?

[SyedAbdulAzeemSF4852]

Looks like the test couldn't catch a bug before fix - could you please verify?

@kubaflo, The gate failed. I verified locally—without the fix, the image renders in monochrome; with the fix, it renders correctly. Below is the screenshot comparison showing the difference with and without the fix.

Without_Fix	With_Fix

[kubaflo]

Could you please check the ai's suggestions?

[MauiBot]

AI Review Summary

@SyedAbdulAzeemSF4852 — new AI review results are available based on this last commit: 35e2e56. To request a fresh review after new comments or commits, comment /review rerun.

---

🚀 Next Steps — review latest findings

No alternative fix was selected for this run. Review the session findings and CI results before merging.

🗂️ Review Sessions — click to expand

🧪 Gate — Test Before & After Fix

Gate Result: ⚠️ INCONCLUSIVE

Platform: WINDOWS · Base: main · Merge base: 4567a055

Test	Without Fix (expect FAIL)	With Fix (expect PASS)
📱 ContextFlyoutTests (MenuFlyoutItemMapSourceSetsShowAsMonochromeToFalse, MenuFlyoutSubItemMapSourceSetsShowAsMonochromeToFalse, MenuFlyoutItemMapSourceSetsShowAsMonochromeToFalseForUriImageSource, MenuFlyoutSubItemMapSourceSetsShowAsMonochromeToFalseForUriImageSource) Category=MenuFlyout	⚠️ ENV ERROR	⚠️ ENV ERROR

🔴 Without fix — 📱 ContextFlyoutTests (MenuFlyoutItemMapSourceSetsShowAsMonochromeToFalse, MenuFlyoutSubItemMapSourceSetsShowAsMonochromeToFalse, MenuFlyoutItemMapSourceSetsShowAsMonochromeToFalseForUriImageSource, MenuFlyoutSubItemMapSourceSetsShowAsMonochromeToFalseForUriImageSource): ⚠️ ENV ERROR · 207s

No log file found

🟢 With fix — 📱 ContextFlyoutTests (MenuFlyoutItemMapSourceSetsShowAsMonochromeToFalse, MenuFlyoutSubItemMapSourceSetsShowAsMonochromeToFalse, MenuFlyoutItemMapSourceSetsShowAsMonochromeToFalseForUriImageSource, MenuFlyoutSubItemMapSourceSetsShowAsMonochromeToFalseForUriImageSource): ⚠️ ENV ERROR · 202s

No log file found

⚠️ Failure Details

• ⚠️ ContextFlyoutTests (MenuFlyoutItemMapSourceSetsShowAsMonochromeToFalse, MenuFlyoutSubItemMapSourceSetsShowAsMonochromeToFalse, MenuFlyoutItemMapSourceSetsShowAsMonochromeToFalseForUriImageSource, MenuFlyoutSubItemMapSourceSetsShowAsMonochromeToFalseForUriImageSource) without fix: Cannot convert the "System.Object[]" value of type "System.Object[]" to type "System.Int32".
• ⚠️ ContextFlyoutTests (MenuFlyoutItemMapSourceSetsShowAsMonochromeToFalse, MenuFlyoutSubItemMapSourceSetsShowAsMonochromeToFalse, MenuFlyoutItemMapSourceSetsShowAsMonochromeToFalseForUriImageSource, MenuFlyoutSubItemMapSourceSetsShowAsMonochromeToFalseForUriImageSource) with fix: Cannot convert the "System.Object[]" value of type "System.Object[]" to type "System.Int32".

📁 Fix files reverted (3 files)

• src/Core/src/Handlers/MenuFlyoutItem/MenuFlyoutItemHandler.Windows.cs
• src/Core/src/Handlers/MenuFlyoutSubItem/MenuFlyoutSubItemHandler.Windows.cs
• src/Core/src/Platform/Windows/ImageExtensions.cs

---

🛫 Pre-Flight — Context & Validation

Issue: #16119 - MenuFlyoutItem with FileImageSource doesn't display icon properly
PR: #32522 - [Windows] Fix for MenuFlyoutItem displaying icon in monochrome instead of original colors
Platforms Affected: Windows
Files Changed: 3 implementation, 1 test

Key Findings

• Issue #16119 reports Windows MenuFlyoutItem FileImageSource icons rendering as a white/monochrome silhouette instead of the original bitmap colors.
• PR changes Windows MenuFlyoutItem and MenuFlyoutSubItem handler source mapping plus Windows image-to-icon conversion so bitmap icon sources can opt out of WinUI monochrome rendering.
• Regression coverage is in Windows Controls device tests for FileImageSource and UriImageSource on MenuFlyoutItem and MenuFlyoutSubItem.
• GitHub CLI is unauthenticated in this environment, so PR comments/checks were gathered only from public API/local branch where possible; the supplied gate result remains inconclusive and was not re-run.

Code Review Summary

Verdict: NEEDS_DISCUSSION
Confidence: low
Errors: 0 | Warnings: 0 | Suggestions: 0

Key code review findings:

• No new actionable code findings.
• Failure mode: null source remains safe via null-conditional mapping.
• Failure mode: font icons keep existing FontIconSource behavior and are not affected by bitmap-only ShowAsMonochrome changes.
• Failure mode: existing ToIconSource(IImageSource, IMauiContext) callers preserve current monochrome default because the new overload defaults preserveWebColors to false.
• Blast radius: Windows-only, scoped to MenuFlyoutItem/MenuFlyoutSubItem icon mapping and bitmap icon conversion; no startup/static/shared state impact.

Fix Candidates

#	Source	Approach	Test Result	Files Changed	Notes
PR	PR #32522	Add internal ToIconSource(..., preserveWebColors: true) overload and use it from Windows MenuFlyoutItem/MenuFlyoutSubItem handlers so bitmap icons set ShowAsMonochrome = false while other callers keep defaults.	⚠️ INCONCLUSIVE (Gate)	ImageExtensions.cs, menu flyout handlers, Windows device tests	Original PR; gate build/run unavailable per supplied result.

---

🔬 Code Review — Deep Analysis

Code Review — PR #32522

Independent Assessment

What this changes: Windows menu flyout item/subitem bitmap icons opt out of WinUI monochrome rendering via an internal ToIconSource(..., preserveWebColors: true) path.
Inferred motivation: Preserve original colors for File/Uri image icons in MenuFlyout scenarios.

Reconciliation with PR Narrative

Author claims: Fixes #16119: MenuFlyoutItem icons render monochrome due to BitmapIconSource.ShowAsMonochrome defaulting true.
Agreement/disagreement: Matches the code. Current diff also adds UriImageSource coverage.

Prior Review Reconciliation

Prior ❌ Error Finding	Source	Status	Evidence
No prior ❌ Error code findings found. Prior URI coverage warnings are now fixed.	MauiBot inline reviews	✅ Fixed / obsolete	Uri tests added at ContextFlyoutTests.Windows.cs:58-100; implementation covers File and Uri branches at ImageExtensions.cs:52,56.

Blast Radius Assessment

• Runs for all instances: No — only Windows MenuFlyoutItem/MenuFlyoutSubItem using icon sources.
• Startup impact: No.
• Static/shared state: No. Shared ToIconSource() default behavior is preserved for existing callers.

CI Status

• Required-check result: Tool unavailable via gh pr checks --required because GitHub CLI is unauthenticated.
• Classification: Gate was already inconclusive from build/environment error; do not treat as PR failure. Public check status could not be reliably classified in this environment.
• Action taken: Confidence capped low due unavailable required-check verification and inconclusive gate.

Findings

No new actionable code findings.

Failure-Mode Probing

• Null source: null-conditional path leaves platform icon null, same as before.
• Font icons: unaffected; only BitmapIconSource branches set ShowAsMonochrome.
• Other ToIconSource() callers: unchanged because public overload passes preserveWebColors: false.
• Handler reconnect/disconnect: no new subscriptions or retained state.

Verdict: NEEDS_DISCUSSION

Confidence: low
Summary: Code looks sound and scoped, with prior URI coverage concerns addressed. Not LGTM because CI/gate verification is unavailable/inconclusive in this environment.

---

🛠️ Fix — Analysis & Comparison

Fix Candidates

#	Source	Approach	Test Result	Files Changed	Notes
1	try-fix	Handler-local post-processing helper: keep shared ToIconSource() unchanged, create the final WinUI IconElement, then set BitmapIcon.ShowAsMonochrome = false only for menu flyout icons.	⚠️ BLOCKED (environment)	4 files	Built to test assembly; VSTest aborted because testhost.dll package file was missing. Narrower blast radius than PR, but relies on mutating final BitmapIcon.
2	try-fix	Menu-specific IconSource factory: keep shared ToIconSource() unchanged, but construct menu File/Uri BitmapIconSource with ShowAsMonochrome = false before CreateIconElement().	⚠️ BLOCKED (environment)	4 files	Built to test assembly; same missing testhost.dll blocker. Avoids post-creation mutation but duplicates File/Uri bitmap conversion logic.
3	try-fix	ImageIconSource/image-service pipeline: avoid BitmapIcon entirely for File/Uri menu icons by loading MAUI platform images and assigning ImageIconSource-backed menu icons.	⚠️ BLOCKED (environment)	4 files	After one compile fix, built to test assembly; same missing testhost.dll blocker. Most distinct and potentially robust, but much more invasive due async loading and changed icon element type.
PR	PR #32522	Add internal ToIconSource(..., preserveWebColors: true) overload and call it from Windows MenuFlyoutItem/MenuFlyoutSubItem handlers so bitmap icon sources opt out of monochrome rendering while default callers preserve existing behavior.	⚠️ INCONCLUSIVE (Gate)	4 files	Original PR; scoped and lower-complexity than image-loader candidate, less duplicated than candidate 2.

Cross-Pollination

Model	Round	New Ideas?	Details
maui-expert-reviewer	1	Yes	Proposed handler-local post-processing of final BitmapIcon/IconElement.
maui-expert-reviewer	1	Yes	Independently converged on the same handler-local post-processing strategy via a Windows menu platform extension.
maui-expert-reviewer	2	Yes	Proposed menu-specific IconSource factory that constructs BitmapIconSource with ShowAsMonochrome = false for menu File/Uri sources only.
maui-expert-reviewer	2	Yes	Proposed avoiding BitmapIcon completely by using MAUI image loading plus ImageIconSource.

Failure / Blocker Pattern

All attempted candidates that reached test execution hit the same Windows VSTest environment blocker:

An assembly specified in the application dependencies manifest (testhost.deps.json) was not found:
  package: 'testhost', version: '18.0.1-release-25523-113'
  path: 'testhost.dll'
Test Run Aborted.

This matches the supplied gate instruction to treat build/run failures as inconclusive environment blockers, not proof of candidate failure.

Exhausted: Yes — meaningfully different implementation families were explored: final-element mutation, menu-specific source factory, and image-loader/ImageIconSource replacement. Additional variants would be trivial renames or relocation of the same policy.

Selected Fix: PR #32522 remains the best supported implementation on code merits. Candidate 2 is the closest alternative but duplicates ImageExtensions File/Uri logic; candidate 1 is narrower but relies on post-processing the final element; candidate 3 is architecturally distinct but too invasive without successful visual/device validation. Because all tests are environment-blocked, no candidate is demonstrably better than the PR's current fix.

---

🏁 Report — Final Recommendation

Comparative Report — PR #32522

Candidates Compared

Candidate	Approach	Regression result	Rank	Assessment
pr	Adds internal ToIconSource(..., preserveWebColors: true) and uses it from Windows MenuFlyoutItem/MenuFlyoutSubItem source mapping so File/URI bitmap icons set ShowAsMonochrome = false; default callers keep monochrome behavior.	INCONCLUSIVE / environment-blocked	1	Best balance of scope, reuse, and behavior preservation.
pr-plus-reviewer	Same as pr; expert reviewer found no actionable changes.	INCONCLUSIVE / environment-blocked	1 (tied)	Functionally identical to pr, so it does not supersede the raw PR fix.
try-fix-2	Adds a menu-specific icon factory that constructs menu File/URI BitmapIconSource values with ShowAsMonochrome = false.	BLOCKED / environment	3	Reasonable and narrow, but duplicates File/URI conversion logic from ImageExtensions.
try-fix-1	Creates the final WinUI IconElement, then post-processes BitmapIcon.ShowAsMonochrome = false for menu icons.	BLOCKED / environment	4	Narrower shared-code blast radius, but less direct because it mutates the created element after source conversion.
try-fix-3	Avoids BitmapIcon for File/URI menu icons by loading MAUI images asynchronously and using ImageIconSource.	BLOCKED / environment after one candidate-local compile fix	5	Most distinct, but materially more invasive and changes timing/icon type; needs successful visual/device validation before it could beat the PR.

No candidate had a confirmed regression-test failure. Per the supplied gate result and STEP 5a logs, test execution was blocked by environment/tooling issues and must not be treated as a failing fix.

Winning Candidate

Winner: pr

The raw PR fix wins because it directly addresses the WinUI monochrome default at the shared IconSource creation point while preserving existing behavior for every current public ToIconSource(...) caller through the default preserveWebColors: false path. pr-plus-reviewer is identical because the expert reviewer found no actionable feedback, so selecting the raw PR is clearer. The try-fix alternatives are plausible but either duplicate conversion logic, mutate the created element after conversion, or introduce a more invasive async image-loading path without successful validation.

Notes for Final Recommendation

The implementation merits discussion rather than a clean LGTM only because CI and Windows regression tests were not verifiable in this environment. The code review found no correctness issue that would justify preferring a try-fix candidate over the submitted PR fix.

[SyedAbdulAzeemSF4852]

@kubaflo , The gate reported the result as INCONCLUSIVE. I verified the scenario locally, and the test passes with the fix applied and fails without the fix.

With_Fix	Without_Fix