[iOS] Fixed LinearGradientBrush in Shell FlyoutBackground misaligned #32137
Conversation
|
Hey there @@SubhikshaSf4851! Thank you so much for your PR! Someone from the team will get assigned to your PR shortly and we'll get it reviewed. |
dotnet-policy-service
bot
added
the
partner/syncfusion
|
/azp run MAUI-UITests-public |
jsuarezruiz
added
the
area-drawing
|
Azure Pipelines successfully started running 1 pipeline(s). |
| App.Tap("navigateButton"); | ||
| App.WaitForElement("welcomeLabel"); | ||
| App.SetOrientationPortrait(); | ||
| VerifyScreenshot(); |
There was a problem hiding this comment.
Running a build, pending snapshots.
There was a problem hiding this comment.
I have updated the snapshots
| UpdateFooterPosition(); | ||
| UpdateFlyoutContent(); | ||
| // Whenever the layout changes, the background needs to be redrawn to match the new view dimensions. This is especially important for gradients. | ||
| UpdateBackground(); |
There was a problem hiding this comment.
I think UpdateBackground() will be called too frequently.
ViewWillLayoutSubviews() is called many times:
- Initial layout
- Orientation change
- Keyboard appearance
- Safe area inset changes
- Parent view layout changes
Can only redraw when size actually changes?
var currentSize = View.Bounds.Size;
if (_lastBackgroundSize != currentSize)
UpdateBackground();
There was a problem hiding this comment.
I have modified the changes
There was a problem hiding this comment.
Pull Request Overview
This PR fixes a rendering issue where LinearGradientBrush in Shell FlyoutBackground was misaligned on iOS after layout changes, particularly during device orientation changes. The gradient wasn't updating because its offsets weren't recalculated when the view's layout changed.
Key Changes:
- Moved background update logic from
ViewDidLoadtoViewWillLayoutSubviewswith bounds checking - Added UI test to verify gradient rendering persists through orientation changes
Reviewed Changes
Copilot reviewed 3 out of 5 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
src/Controls/src/Core/Compatibility/Handlers/Shell/iOS/ShellFlyoutContentRenderer.cs |
Moved UpdateBackground() call from ViewDidLoad to ViewWillLayoutSubviews with bounds tracking to redraw gradient on layout changes |
src/Controls/tests/TestCases.HostApp/Issues/Issue27822.cs |
Added test page demonstrating the gradient background issue in Shell flyout |
src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue27822.cs |
Added automated UI test that verifies gradient rendering after orientation change |
| var currentSize = View.Bounds.Size; | ||
| if (_previousBounds != currentSize) | ||
| { | ||
| // Whenever the layout changes, the background needs to be redrawn to match the new view dimensions. This is especially important for gradients. | ||
| UpdateBackground(); | ||
| _previousBounds = currentSize; | ||
| } |
There was a problem hiding this comment.
[nitpick] The background is redrawn on every layout change, which could be called multiple times during animations or layout passes. Consider adding a small tolerance check or debouncing to avoid unnecessary redraws during minor layout adjustments.
|
/azp run |
|
Azure Pipelines successfully started running 3 pipeline(s). |
3 participants
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!
RootCause
The gradient didn’t update after layout changes because its offsets weren’t recalculated when the view’s layout changed. Solid colors weren’t affected since they don’t depend on offsets.
Description of Change
Ensured the background is redrawn on every layout change by calling
UpdateBackground()inViewWillLayoutSubviewsinstead of only inViewDidLoadinShellFlyoutContentRenderer.cs, fixing gradient rendering issues.Issues Fixed
Fixes #27822
Tested the behavior in the following platforms
Screenshot
WithoutFixIssue27822.mp4
Untitled.4.mp4