Skip to content

Comments

Fix for Control does not update from binding anymore after MultiBinding.ConvertBack is called#33128

Merged
PureWeen merged 1 commit intodotnet:inflight/currentfrom
BagavathiPerumal:fix-24969
Dec 22, 2025
Merged

Fix for Control does not update from binding anymore after MultiBinding.ConvertBack is called#33128
PureWeen merged 1 commit intodotnet:inflight/currentfrom
BagavathiPerumal:fix-24969

Conversation

@BagavathiPerumal
Copy link
Contributor

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:

The issue occurs because a TwoWay MultiBinding executes its ConvertBack method after the control has been manually modified. Although ConvertBack correctly updates the ViewModel, subsequent ViewModel changes no longer update the UI, causing the binding to become unresponsive.

The underlying problem is a priority conflict. A manual modification is applied with ManualValueSetter priority (level 3), while updates from the binding use FromBinding priority (level 5), which is lower. Because lower-priority updates cannot override higher-priority ones, the binding system blocks further UI updates originating from the ViewModel.

Fix Description:

The fix involves applying MultiBinding updates using ManualValueSetter instead of FromBinding within the MultiBinding.Apply method. This allows the binding to override the previous manual modification and maintain control of the target property, ensuring that UI updates continue to reflect changes in the ViewModel.

Issues Fixed

Fixes #24969
Fixes #20382

Tested the behaviour in the following platforms

  • Android
  • Windows
  • iOS
  • Mac

Output Screenshot

Before Issue Fix After Issue Fix
MultiBinding-BeforeFix.mov
MultiBinding-AfterFix.mov

@sheiksyedm
Copy link
Contributor

sheiksyedm commented Dec 15, 2025

/rebase

Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR fixes a critical bug where MultiBinding with TwoWay mode stops updating the UI after ConvertBack is called. The issue was caused by a specificity conflict where manual value modifications (priority 3) blocked subsequent binding updates (priority 5). The fix changes MultiBinding to use ManualValueSetter priority for its updates, ensuring the binding can override previous manual modifications.

  • Changes the specificity used in MultiBinding.Apply from FromBinding to ManualValueSetter
  • Adds a comprehensive unit test validating that bindings continue to update after ConvertBack is called

Reviewed changes

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

File Description
src/Controls/src/Core/MultiBinding.cs Updates SetterSpecificity from FromBinding to ManualValueSetter in the Apply method to allow binding updates to override manual modifications
src/Controls/tests/Core.UnitTests/MultiBindingTests.cs Adds test case TestMultiBindingContinuesUpdatingAfterConvertBack that validates the fix by setting up a TwoWay MultiBinding, manually updating the control, and verifying subsequent ViewModel changes still update the UI

The changes are well-targeted and correctly address the root cause. The test coverage properly validates the fix by reproducing the exact scenario described in the linked issues.

@sheiksyedm
Copy link
Contributor

/rebase

…ertBack by using ManualValueSetter instead of FromBinding specificity.
Copy link
Contributor

@StephaneDelcroix StephaneDelcroix left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

✅ Approved

Fix validated through:

  1. Unit tests: All 10 MultiBinding tests pass, including the new TestMultiBindingContinuesUpdatingAfterConvertBack test
  2. Sandbox reproduction: Confirmed fix works on Android - after ConvertBack is triggered, ViewModel property changes correctly update the UI
  3. Code review: The specificity change from FromBinding to ManualValueSetter is the correct solution

Why this fix is correct:

  • Manual modifications set values with ManualValueSetter priority (higher)
  • FromBinding priority (lower) was being blocked by higher-priority values
  • Using ManualValueSetter ensures MultiBinding can always update the UI after manual modifications
  • Still respects VSM and Handler priorities (which are higher)

No regressions: All 588 binding-related tests pass.

Great fix! 🎉

@PureWeen PureWeen changed the base branch from main to inflight/current December 22, 2025 17:33
@PureWeen PureWeen merged commit dbeff99 into dotnet:inflight/current Dec 22, 2025
155 of 159 checks passed
PureWeen pushed a commit that referenced this pull request Dec 22, 2025
…ng.ConvertBack is called (#33128)

<!-- Please let the below note in for people that find this PR -->
> [!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!

<!--
!!!!!!! MAIN IS THE ONLY ACTIVE BRANCH. MAKE SURE THIS PR IS TARGETING
MAIN. !!!!!!!
-->

### Root Cause:

The issue occurs because a TwoWay MultiBinding executes its ConvertBack
method after the control has been manually modified. Although
ConvertBack correctly updates the ViewModel, subsequent ViewModel
changes no longer update the UI, causing the binding to become
unresponsive.

The underlying problem is a priority conflict. A manual modification is
applied with ManualValueSetter priority (level 3), while updates from
the binding use FromBinding priority (level 5), which is lower. Because
lower-priority updates cannot override higher-priority ones, the binding
system blocks further UI updates originating from the ViewModel.

### Fix Description:

The fix involves applying MultiBinding updates
using ManualValueSetter instead of FromBinding within the
MultiBinding.Apply method. This allows the binding to override the
previous manual modification and maintain control of the target
property, ensuring that UI updates continue to reflect changes in the
ViewModel.

### Issues Fixed
Fixes #24969
Fixes #20382

### Tested the behaviour in the following platforms
- [x] Android
- [x] Windows
- [x] iOS
- [x] Mac

### Output Screenshot
Before Issue Fix | After Issue Fix |
|----------|----------|
|<video width="100" height="100" alt="Before Fix"
src="https://github.com/user-attachments/assets/e603570a-1129-451b-8d10-deecbba52879">|<video
width="100" height="100" alt="After Fix"
src="https://github.com/user-attachments/assets/c1097645-b990-4a6e-a2c1-a4f1991018a9">|
PureWeen pushed a commit that referenced this pull request Dec 26, 2025
…ng.ConvertBack is called (#33128)

<!-- Please let the below note in for people that find this PR -->
> [!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!

<!--
!!!!!!! MAIN IS THE ONLY ACTIVE BRANCH. MAKE SURE THIS PR IS TARGETING
MAIN. !!!!!!!
-->

### Root Cause:

The issue occurs because a TwoWay MultiBinding executes its ConvertBack
method after the control has been manually modified. Although
ConvertBack correctly updates the ViewModel, subsequent ViewModel
changes no longer update the UI, causing the binding to become
unresponsive.

The underlying problem is a priority conflict. A manual modification is
applied with ManualValueSetter priority (level 3), while updates from
the binding use FromBinding priority (level 5), which is lower. Because
lower-priority updates cannot override higher-priority ones, the binding
system blocks further UI updates originating from the ViewModel.

### Fix Description:

The fix involves applying MultiBinding updates
using ManualValueSetter instead of FromBinding within the
MultiBinding.Apply method. This allows the binding to override the
previous manual modification and maintain control of the target
property, ensuring that UI updates continue to reflect changes in the
ViewModel.

### Issues Fixed
Fixes #24969
Fixes #20382

### Tested the behaviour in the following platforms
- [x] Android
- [x] Windows
- [x] iOS
- [x] Mac

### Output Screenshot
Before Issue Fix | After Issue Fix |
|----------|----------|
|<video width="100" height="100" alt="Before Fix"
src="https://github.com/user-attachments/assets/e603570a-1129-451b-8d10-deecbba52879">|<video
width="100" height="100" alt="After Fix"
src="https://github.com/user-attachments/assets/c1097645-b990-4a6e-a2c1-a4f1991018a9">|
PureWeen pushed a commit that referenced this pull request Dec 30, 2025
…ng.ConvertBack is called (#33128)

<!-- Please let the below note in for people that find this PR -->
> [!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!

<!--
!!!!!!! MAIN IS THE ONLY ACTIVE BRANCH. MAKE SURE THIS PR IS TARGETING
MAIN. !!!!!!!
-->

### Root Cause:

The issue occurs because a TwoWay MultiBinding executes its ConvertBack
method after the control has been manually modified. Although
ConvertBack correctly updates the ViewModel, subsequent ViewModel
changes no longer update the UI, causing the binding to become
unresponsive.

The underlying problem is a priority conflict. A manual modification is
applied with ManualValueSetter priority (level 3), while updates from
the binding use FromBinding priority (level 5), which is lower. Because
lower-priority updates cannot override higher-priority ones, the binding
system blocks further UI updates originating from the ViewModel.

### Fix Description:

The fix involves applying MultiBinding updates
using ManualValueSetter instead of FromBinding within the
MultiBinding.Apply method. This allows the binding to override the
previous manual modification and maintain control of the target
property, ensuring that UI updates continue to reflect changes in the
ViewModel.

### Issues Fixed
Fixes #24969
Fixes #20382

### Tested the behaviour in the following platforms
- [x] Android
- [x] Windows
- [x] iOS
- [x] Mac

### Output Screenshot
Before Issue Fix | After Issue Fix |
|----------|----------|
|<video width="100" height="100" alt="Before Fix"
src="https://github.com/user-attachments/assets/e603570a-1129-451b-8d10-deecbba52879">|<video
width="100" height="100" alt="After Fix"
src="https://github.com/user-attachments/assets/c1097645-b990-4a6e-a2c1-a4f1991018a9">|
github-actions bot pushed a commit that referenced this pull request Dec 30, 2025
…ng.ConvertBack is called (#33128)

<!-- Please let the below note in for people that find this PR -->
> [!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!

<!--
!!!!!!! MAIN IS THE ONLY ACTIVE BRANCH. MAKE SURE THIS PR IS TARGETING
MAIN. !!!!!!!
-->

### Root Cause:

The issue occurs because a TwoWay MultiBinding executes its ConvertBack
method after the control has been manually modified. Although
ConvertBack correctly updates the ViewModel, subsequent ViewModel
changes no longer update the UI, causing the binding to become
unresponsive.

The underlying problem is a priority conflict. A manual modification is
applied with ManualValueSetter priority (level 3), while updates from
the binding use FromBinding priority (level 5), which is lower. Because
lower-priority updates cannot override higher-priority ones, the binding
system blocks further UI updates originating from the ViewModel.

### Fix Description:

The fix involves applying MultiBinding updates
using ManualValueSetter instead of FromBinding within the
MultiBinding.Apply method. This allows the binding to override the
previous manual modification and maintain control of the target
property, ensuring that UI updates continue to reflect changes in the
ViewModel.

### Issues Fixed
Fixes #24969
Fixes #20382

### Tested the behaviour in the following platforms
- [x] Android
- [x] Windows
- [x] iOS
- [x] Mac

### Output Screenshot
Before Issue Fix | After Issue Fix |
|----------|----------|
|<video width="100" height="100" alt="Before Fix"
src="https://github.com/user-attachments/assets/e603570a-1129-451b-8d10-deecbba52879">|<video
width="100" height="100" alt="After Fix"
src="https://github.com/user-attachments/assets/c1097645-b990-4a6e-a2c1-a4f1991018a9">|
PureWeen pushed a commit that referenced this pull request Jan 5, 2026
…ng.ConvertBack is called (#33128)

<!-- Please let the below note in for people that find this PR -->
> [!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!

<!--
!!!!!!! MAIN IS THE ONLY ACTIVE BRANCH. MAKE SURE THIS PR IS TARGETING
MAIN. !!!!!!!
-->

### Root Cause:

The issue occurs because a TwoWay MultiBinding executes its ConvertBack
method after the control has been manually modified. Although
ConvertBack correctly updates the ViewModel, subsequent ViewModel
changes no longer update the UI, causing the binding to become
unresponsive.

The underlying problem is a priority conflict. A manual modification is
applied with ManualValueSetter priority (level 3), while updates from
the binding use FromBinding priority (level 5), which is lower. Because
lower-priority updates cannot override higher-priority ones, the binding
system blocks further UI updates originating from the ViewModel.

### Fix Description:

The fix involves applying MultiBinding updates
using ManualValueSetter instead of FromBinding within the
MultiBinding.Apply method. This allows the binding to override the
previous manual modification and maintain control of the target
property, ensuring that UI updates continue to reflect changes in the
ViewModel.

### Issues Fixed
Fixes #24969
Fixes #20382

### Tested the behaviour in the following platforms
- [x] Android
- [x] Windows
- [x] iOS
- [x] Mac

### Output Screenshot
Before Issue Fix | After Issue Fix |
|----------|----------|
|<video width="100" height="100" alt="Before Fix"
src="https://github.com/user-attachments/assets/e603570a-1129-451b-8d10-deecbba52879">|<video
width="100" height="100" alt="After Fix"
src="https://github.com/user-attachments/assets/c1097645-b990-4a6e-a2c1-a4f1991018a9">|
@PureWeen PureWeen mentioned this pull request Jan 7, 2026
PureWeen pushed a commit that referenced this pull request Jan 9, 2026
…ng.ConvertBack is called (#33128)

<!-- Please let the below note in for people that find this PR -->
> [!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!

<!--
!!!!!!! MAIN IS THE ONLY ACTIVE BRANCH. MAKE SURE THIS PR IS TARGETING
MAIN. !!!!!!!
-->

### Root Cause:

The issue occurs because a TwoWay MultiBinding executes its ConvertBack
method after the control has been manually modified. Although
ConvertBack correctly updates the ViewModel, subsequent ViewModel
changes no longer update the UI, causing the binding to become
unresponsive.

The underlying problem is a priority conflict. A manual modification is
applied with ManualValueSetter priority (level 3), while updates from
the binding use FromBinding priority (level 5), which is lower. Because
lower-priority updates cannot override higher-priority ones, the binding
system blocks further UI updates originating from the ViewModel.

### Fix Description:

The fix involves applying MultiBinding updates
using ManualValueSetter instead of FromBinding within the
MultiBinding.Apply method. This allows the binding to override the
previous manual modification and maintain control of the target
property, ensuring that UI updates continue to reflect changes in the
ViewModel.

### Issues Fixed
Fixes #24969
Fixes #20382

### Tested the behaviour in the following platforms
- [x] Android
- [x] Windows
- [x] iOS
- [x] Mac

### Output Screenshot
Before Issue Fix | After Issue Fix |
|----------|----------|
|<video width="100" height="100" alt="Before Fix"
src="https://github.com/user-attachments/assets/e603570a-1129-451b-8d10-deecbba52879">|<video
width="100" height="100" alt="After Fix"
src="https://github.com/user-attachments/assets/c1097645-b990-4a6e-a2c1-a4f1991018a9">|
PureWeen pushed a commit that referenced this pull request Jan 9, 2026
…ng.ConvertBack is called (#33128)

<!-- Please let the below note in for people that find this PR -->
> [!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!

<!--
!!!!!!! MAIN IS THE ONLY ACTIVE BRANCH. MAKE SURE THIS PR IS TARGETING
MAIN. !!!!!!!
-->

### Root Cause:

The issue occurs because a TwoWay MultiBinding executes its ConvertBack
method after the control has been manually modified. Although
ConvertBack correctly updates the ViewModel, subsequent ViewModel
changes no longer update the UI, causing the binding to become
unresponsive.

The underlying problem is a priority conflict. A manual modification is
applied with ManualValueSetter priority (level 3), while updates from
the binding use FromBinding priority (level 5), which is lower. Because
lower-priority updates cannot override higher-priority ones, the binding
system blocks further UI updates originating from the ViewModel.

### Fix Description:

The fix involves applying MultiBinding updates
using ManualValueSetter instead of FromBinding within the
MultiBinding.Apply method. This allows the binding to override the
previous manual modification and maintain control of the target
property, ensuring that UI updates continue to reflect changes in the
ViewModel.

### Issues Fixed
Fixes #24969
Fixes #20382

### Tested the behaviour in the following platforms
- [x] Android
- [x] Windows
- [x] iOS
- [x] Mac

### Output Screenshot
Before Issue Fix | After Issue Fix |
|----------|----------|
|<video width="100" height="100" alt="Before Fix"
src="https://github.com/user-attachments/assets/e603570a-1129-451b-8d10-deecbba52879">|<video
width="100" height="100" alt="After Fix"
src="https://github.com/user-attachments/assets/c1097645-b990-4a6e-a2c1-a4f1991018a9">|
PureWeen pushed a commit that referenced this pull request Jan 9, 2026
…ng.ConvertBack is called (#33128)

<!-- Please let the below note in for people that find this PR -->
> [!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!

<!--
!!!!!!! MAIN IS THE ONLY ACTIVE BRANCH. MAKE SURE THIS PR IS TARGETING
MAIN. !!!!!!!
-->

### Root Cause:

The issue occurs because a TwoWay MultiBinding executes its ConvertBack
method after the control has been manually modified. Although
ConvertBack correctly updates the ViewModel, subsequent ViewModel
changes no longer update the UI, causing the binding to become
unresponsive.

The underlying problem is a priority conflict. A manual modification is
applied with ManualValueSetter priority (level 3), while updates from
the binding use FromBinding priority (level 5), which is lower. Because
lower-priority updates cannot override higher-priority ones, the binding
system blocks further UI updates originating from the ViewModel.

### Fix Description:

The fix involves applying MultiBinding updates
using ManualValueSetter instead of FromBinding within the
MultiBinding.Apply method. This allows the binding to override the
previous manual modification and maintain control of the target
property, ensuring that UI updates continue to reflect changes in the
ViewModel.

### Issues Fixed
Fixes #24969
Fixes #20382

### Tested the behaviour in the following platforms
- [x] Android
- [x] Windows
- [x] iOS
- [x] Mac

### Output Screenshot
Before Issue Fix | After Issue Fix |
|----------|----------|
|<video width="100" height="100" alt="Before Fix"
src="https://github.com/user-attachments/assets/e603570a-1129-451b-8d10-deecbba52879">|<video
width="100" height="100" alt="After Fix"
src="https://github.com/user-attachments/assets/c1097645-b990-4a6e-a2c1-a4f1991018a9">|
PureWeen pushed a commit that referenced this pull request Jan 13, 2026
…ng.ConvertBack is called (#33128)

<!-- Please let the below note in for people that find this PR -->
> [!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!

<!--
!!!!!!! MAIN IS THE ONLY ACTIVE BRANCH. MAKE SURE THIS PR IS TARGETING
MAIN. !!!!!!!
-->

### Root Cause:

The issue occurs because a TwoWay MultiBinding executes its ConvertBack
method after the control has been manually modified. Although
ConvertBack correctly updates the ViewModel, subsequent ViewModel
changes no longer update the UI, causing the binding to become
unresponsive.

The underlying problem is a priority conflict. A manual modification is
applied with ManualValueSetter priority (level 3), while updates from
the binding use FromBinding priority (level 5), which is lower. Because
lower-priority updates cannot override higher-priority ones, the binding
system blocks further UI updates originating from the ViewModel.

### Fix Description:

The fix involves applying MultiBinding updates
using ManualValueSetter instead of FromBinding within the
MultiBinding.Apply method. This allows the binding to override the
previous manual modification and maintain control of the target
property, ensuring that UI updates continue to reflect changes in the
ViewModel.

### Issues Fixed
Fixes #24969
Fixes #20382

### Tested the behaviour in the following platforms
- [x] Android
- [x] Windows
- [x] iOS
- [x] Mac

### Output Screenshot
Before Issue Fix | After Issue Fix |
|----------|----------|
|<video width="100" height="100" alt="Before Fix"
src="https://github.com/user-attachments/assets/e603570a-1129-451b-8d10-deecbba52879">|<video
width="100" height="100" alt="After Fix"
src="https://github.com/user-attachments/assets/c1097645-b990-4a6e-a2c1-a4f1991018a9">|
PureWeen pushed a commit that referenced this pull request Jan 13, 2026
…ng.ConvertBack is called (#33128)

<!-- Please let the below note in for people that find this PR -->
> [!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!

<!--
!!!!!!! MAIN IS THE ONLY ACTIVE BRANCH. MAKE SURE THIS PR IS TARGETING
MAIN. !!!!!!!
-->

### Root Cause:

The issue occurs because a TwoWay MultiBinding executes its ConvertBack
method after the control has been manually modified. Although
ConvertBack correctly updates the ViewModel, subsequent ViewModel
changes no longer update the UI, causing the binding to become
unresponsive.

The underlying problem is a priority conflict. A manual modification is
applied with ManualValueSetter priority (level 3), while updates from
the binding use FromBinding priority (level 5), which is lower. Because
lower-priority updates cannot override higher-priority ones, the binding
system blocks further UI updates originating from the ViewModel.

### Fix Description:

The fix involves applying MultiBinding updates
using ManualValueSetter instead of FromBinding within the
MultiBinding.Apply method. This allows the binding to override the
previous manual modification and maintain control of the target
property, ensuring that UI updates continue to reflect changes in the
ViewModel.

### Issues Fixed
Fixes #24969
Fixes #20382

### Tested the behaviour in the following platforms
- [x] Android
- [x] Windows
- [x] iOS
- [x] Mac

### Output Screenshot
Before Issue Fix | After Issue Fix |
|----------|----------|
|<video width="100" height="100" alt="Before Fix"
src="https://github.com/user-attachments/assets/e603570a-1129-451b-8d10-deecbba52879">|<video
width="100" height="100" alt="After Fix"
src="https://github.com/user-attachments/assets/c1097645-b990-4a6e-a2c1-a4f1991018a9">|
PureWeen added a commit that referenced this pull request Jan 13, 2026
## What's Coming

.NET MAUI inflight/candidate introduces significant improvements across
all platforms with focus on quality, performance, and developer
experience. This release includes 27 commits with various improvements,
bug fixes, and enhancements.

## CollectionView
- [iOS][CV2] Fix page can be dragged down, and it would cause an extra
space between Header and EmptyView text by @devanathan-vaithiyanathan in
#31840
  <details>
  <summary>🔧 Fixes</summary>

- [I8_Header_and_Footer_Null - The page can be dragged down, and it
would cause an extra space between Header and EmptyView
text.](#31465)
  </details>

- [iOS] Fixed the Items not displayed properly in CarouselView2 by
@Ahamed-Ali in #31336
  <details>
  <summary>🔧 Fixes</summary>

- [[iOS] Items are not updated properly in
CarouselView2.](#31148)
  </details>

## Docs
- Improve Controls Core API docs by @jfversluis in
#33240

## Editor
- [iOS] Fixed an issue where an Editor with a small height inside a
ScrollView would cause the entire page to scroll by
@Tamilarasan-Paranthaman in #27948
  <details>
  <summary>🔧 Fixes</summary>

- [[iOS][Editor] An Editor that has not enough height and resides inside
a ScrollView/CollectionView will scroll the entire
page](#27750)
  </details>

## Image
- [Android] Image control crashes on Android when image width exceeds
height by @KarthikRajaKalaimani in
#33045
  <details>
  <summary>🔧 Fixes</summary>

- [Image control crashes on Android when image width exceeds
height](#32869)
  </details>

## Mediapicker
- [Android 🤖] Add a log telling why the request is cancelled by @pictos
in #33295
  <details>
  <summary>🔧 Fixes</summary>

- [MediaPicker.PickPhotosAsync throwing TaskCancelledException in
net10-android](#33283)
  </details>

## Navigation
- [Android] Fix for App Hang When PopModalAsync Is Called Immediately
After PushModalAsync with Task.Yield() by @BagavathiPerumal in
#32479
  <details>
  <summary>🔧 Fixes</summary>

- [App hangs if PopModalAsync is called after PushModalAsync with single
await Task.Yield()](#32310)
  </details>

- [iOS 26] Navigation hangs after rapidly open and closing new page
using Navigation.PushAsync - fix by @kubaflo in
#32456
  <details>
  <summary>🔧 Fixes</summary>

- [[iOS 26] Navigation hangs after rapidly open and closing new page
using Navigation.PushAsync](#32425)
  </details>

## Pages
- [iOS] Fix ContentPage BackgroundImageSource not working by
@Shalini-Ashokan in #33297
  <details>
  <summary>🔧 Fixes</summary>

- [.Net MAUI- Page.BackgroundImageSource not working for
iOS](#21594)
  </details>

## RadioButton
- [Issue-Resolver] Fix #33264 - RadioButtonGroup not working with
Collection View by @kubaflo in #33343
  <details>
  <summary>🔧 Fixes</summary>

- [RadioButtonGroup not working with
CollectionView](#33264)
  </details>

## SafeArea
- [Android] Fixed Label Overlapped by Android Status Bar When Using
SafeAreaEdges="Container" in .NET MAUI by @NirmalKumarYuvaraj in
#33285
  <details>
  <summary>🔧 Fixes</summary>

- [SafeAreaEdges works correctly only on the first tab in Shell. Other
tabs have content colliding with the display cutout in the landscape
mode.](#33034)
- [Label Overlapped by Android Status Bar When Using
SafeAreaEdges="Container" in .NET
MAUI](#32941)
- [[MAUI 10] Layout breaks on first navigation (Shell // route) until
soft keyboard appears/disappears (Android +
iOS)](#33038)
  </details>

## ScrollView
- [Windows, Android] Fix ScrollView Content Not Removed When Set to Null
by @devanathan-vaithiyanathan in
#33069
  <details>
  <summary>🔧 Fixes</summary>

- [[Windows, Android] ScrollView Content Not Removed When Set to
Null](#33067)
  </details>

## Searchbar
- Fix Android crash when changing shared Drawable tint on Searchbar by
@tritter in #33071
  <details>
  <summary>🔧 Fixes</summary>

- [[Android] Crash on changing Tint of
Searchbar](#33070)
  </details>

## Shell
- [iOS] - Fix Custom FlyoutIcon from Being Overridden to Default Color
in Shell by @prakashKannanSf3972 in
#27580
  <details>
  <summary>🔧 Fixes</summary>

- [Change the flyout icon
color](#6738)
  </details>

- [iOS] Fix Shell NavBarIsVisible updates when switching ShellContent by
@Vignesh-SF3580 in #33195
  <details>
  <summary>🔧 Fixes</summary>

- [[iOS] Shell NavBarIsVisible is not updated when changing
ShellContent](#33191)
  </details>

## Slider
- [C] Fix Slider and Stepper property order independence by
@StephaneDelcroix in #32939
  <details>
  <summary>🔧 Fixes</summary>

- [Slider Binding Initialization Order Causes Incorrect Value Assignment
in XAML](#32903)
- [Slider is very broken, Value is a mess when setting
Minimum](#14472)
- [Slider is buggy depending on order of
properties](#18910)
- [Stepper Value is incorrectly clamped to default min/max when using
bindableproperties in MVVM
pattern](#12243)
- [[Issue-Resolver] Fix #32903 - Sliderbinding initialization order
issue](#32907)
  </details>

## Stepper
- [Windows] Maui Stepper: Clamp minimum and maximum value by @OomJan in
#33275
  <details>
  <summary>🔧 Fixes</summary>

- [[Windows] Maui Stepper is not clamped to minimum or maximum
internally](#33274)
  </details>

- [iOS] Fixed the UIStepper Value from being clamped based on old higher
MinimumValue - Candidate PR test failure fix- 33363 by @Ahamed-Ali in
#33392

## TabbedPage
- [windows] Fixed Rapid change of selected tab results in crash. by
@praveenkumarkarunanithi in #33113
  <details>
  <summary>🔧 Fixes</summary>

- [Rapid change of selected tab results in crash on
Windows.](#32824)
  </details>

## Titlebar
- [Mac] Fix TitleBar Content Overlapping with Traffic Light Buttons on
Latest macOS Version by @devanathan-vaithiyanathan in
#33157
  <details>
  <summary>🔧 Fixes</summary>

- [TitleBar Content Overlapping with Traffic Light Buttons on Latest
macOS Version](#33136)
  </details>

## Xaml
- Fix for Control does not update from binding anymore after
MultiBinding.ConvertBack is called by @BagavathiPerumal in
#33128
  <details>
  <summary>🔧 Fixes</summary>

- [Control does not update from binding anymore after
MultiBinding.ConvertBack is
called](#24969)
- [The issue with the MultiBinding converter with two way binding mode
does not work properly when changing the
values.](#20382)
  </details>


<details>
<summary>🔧 Infrastructure (1)</summary>

- Avoid KVO on CALayer by introducing an Apple PlatformInterop by
@albyrock87 in #30861

</details>

<details>
<summary>🧪 Testing (2)</summary>

- [Testing] Enable UITest Issue18193 on MacCatalyst by @NafeelaNazhir in
#31653
  <details>
  <summary>🔧 Fixes</summary>

- [Test Issue18193 was disabled on Mac
Catalyst](#27206)
  </details>
- Set the CV2 handlers as the default by @Ahamed-Ali in
#33177

</details>

<details>
<summary>📦 Other (3)</summary>

- Update WindowsAppSDK to 1.8 by @mattleibow in
#32174
  <details>
  <summary>🔧 Fixes</summary>

- [Update to WindowsAppSDK](#30858)
  </details>
- Fix command dependency reentrancy by @simonrozsival in
#33129
- Fix SafeArea AdjustPan handling and add AdjustNothing mode tests by
@PureWeen via @Copilot in #33354

</details>
**Full Changelog**:
main...inflight/candidate
kubaflo pushed a commit to kubaflo/maui that referenced this pull request Jan 16, 2026
…ng.ConvertBack is called (dotnet#33128)

<!-- Please let the below note in for people that find this PR -->
> [!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!

<!--
!!!!!!! MAIN IS THE ONLY ACTIVE BRANCH. MAKE SURE THIS PR IS TARGETING
MAIN. !!!!!!!
-->

### Root Cause:

The issue occurs because a TwoWay MultiBinding executes its ConvertBack
method after the control has been manually modified. Although
ConvertBack correctly updates the ViewModel, subsequent ViewModel
changes no longer update the UI, causing the binding to become
unresponsive.

The underlying problem is a priority conflict. A manual modification is
applied with ManualValueSetter priority (level 3), while updates from
the binding use FromBinding priority (level 5), which is lower. Because
lower-priority updates cannot override higher-priority ones, the binding
system blocks further UI updates originating from the ViewModel.

### Fix Description:

The fix involves applying MultiBinding updates
using ManualValueSetter instead of FromBinding within the
MultiBinding.Apply method. This allows the binding to override the
previous manual modification and maintain control of the target
property, ensuring that UI updates continue to reflect changes in the
ViewModel.

### Issues Fixed
Fixes dotnet#24969
Fixes dotnet#20382

### Tested the behaviour in the following platforms
- [x] Android
- [x] Windows
- [x] iOS
- [x] Mac

### Output Screenshot
Before Issue Fix | After Issue Fix |
|----------|----------|
|<video width="100" height="100" alt="Before Fix"
src="https://github.com/user-attachments/assets/e603570a-1129-451b-8d10-deecbba52879">|<video
width="100" height="100" alt="After Fix"
src="https://github.com/user-attachments/assets/c1097645-b990-4a6e-a2c1-a4f1991018a9">|
@github-actions github-actions bot locked and limited conversation to collaborators Jan 22, 2026
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

community ✨ Community Contribution partner/syncfusion Issues / PR's with Syncfusion collaboration

Projects

None yet

5 participants