You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
GitHub Issue: related to unoplatform/kahua-private#512
PR Type:
🐞 Bugfix
What changed? 🚀
On Skia targets, a focused field could stay clipped or hidden behind the on-screen keyboard. This happened whenever the field's nearest ScrollViewer could not move it high enough, for example a details side panel whose ScrollViewer starts just above the keyboard's top edge (and worse in iPad Safari with the tab bar showing). InputPane only padded and scrolled that one ScrollContentPresenter, and nothing moved the rest of the content. In WinUI, the RootScrollViewer shrinks to the area above the input pane and scrolls the whole content instead. This PR replaces the padding with the equivalent of that RootScrollViewer. While the input pane is shown, the window's root element (RootVisual or XamlIslandRoot, through UnoRootElementLogic) acts as the outermost bring-into-view scroller, with a viewport that ends at the top of the pane. It offsets the public root visual when the focused element, padded by WinUI's 20px, still sits below that viewport, and resets the offset when the pane hides. InputPane now requests a non-animated bring-into-view, as WinUI does. Two related fixes: ScrollContentPresenter's bring-into-view used the DesiredSize-based viewport, which dropped requests coming from content stretched taller than it asks for instead of forwarding them to outer scrollers; and AutoSuggestBox now places its suggestion list in window coordinates, since the content can be offset. Given_InputPane now covers a side panel that starts near the keyboard, a field outside any ScrollViewer, focus moving while the keyboard is up, hit-testing after the content moves, restoring the content when the keyboard hides, and an app that handles Showing itself. Given_ScrollViewer covers the nested stretched-content case. Both fail without the fix. The change was also checked manually on an iPad in Safari with the SoftKeyboardFocusTests sample, whose steps are updated for the new behavior.
This caps root scrolling to the host window height, not the public root visual's extent. XamlIslandRoot.ArrangeOverride explicitly allows that visual to be taller than the host (Math.Max(finalSize.Height, childDesiredSize.Height)), so moving focus to a field farther down a tall root StackPanel while the keyboard is open can require more than the keyboard-height offset and will remain occluded. Compute the maximum from the larger of the host and public-root heights (and cover a tall root without an inner ScrollViewer).
On branch mergify/bp/servicing/6.8/pr-24947
Your branch is ahead of 'origin/servicing/6.8' by 1 commit.
(use "git push" to publish your local commits)
You are currently cherry-picking commit 1b9aeab.
(fix conflicts and run "git cherry-pick --continue")
(use "git cherry-pick --skip" to skip this patch)
(use "git cherry-pick --abort" to cancel the cherry-pick operation)
Changes to be committed:
modified: src/Uno.UI.RuntimeTests/Tests/Windows_UI_ViewManagement/Given_InputPane.cs
modified: src/Uno.UI/UI/Xaml/Controls/ScrollContentPresenter/ScrollContentPresenter.cs
modified: src/Uno.UI/UI/Xaml/Internal/IRootElement.cs
modified: src/Uno.UI/UI/Xaml/Internal/Islands/XamlIslandRoot.Core.cs
modified: src/Uno.UI/UI/Xaml/Internal/Islands/XamlIslandRoot.uno.cs
modified: src/Uno.UI/UI/Xaml/Internal/RootVisual.cs
new file: src/Uno.UI/UI/Xaml/Internal/RootVisual.uno.cs
modified: src/Uno.UI/UI/Xaml/Internal/UnoRootElementLogic.cs
Unmerged paths:
(use "git add/rm <file>..." as appropriate to mark resolution)
both modified: src/Uno.UI/UI/ViewManagement/InputPane/InputPane.cs
deleted by them: src/Uno.UI/UI/Xaml/Controls/ScrollContentPresenter/ScrollContentPresenter.OccludedPadding.cs
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
area/automationCategorizes an issue or PR as relevant to project automation
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
GitHub Issue: related to unoplatform/kahua-private#512
PR Type:
🐞 Bugfix
What changed? 🚀
On Skia targets, a focused field could stay clipped or hidden behind the on-screen keyboard. This happened whenever the field's nearest
ScrollViewercould not move it high enough, for example a details side panel whoseScrollViewerstarts just above the keyboard's top edge (and worse in iPad Safari with the tab bar showing).InputPaneonly padded and scrolled that oneScrollContentPresenter, and nothing moved the rest of the content. In WinUI, theRootScrollViewershrinks to the area above the input pane and scrolls the whole content instead. This PR replaces the padding with the equivalent of thatRootScrollViewer. While the input pane is shown, the window's root element (RootVisualorXamlIslandRoot, throughUnoRootElementLogic) acts as the outermost bring-into-view scroller, with a viewport that ends at the top of the pane. It offsets the public root visual when the focused element, padded by WinUI's 20px, still sits below that viewport, and resets the offset when the pane hides.InputPanenow requests a non-animated bring-into-view, as WinUI does. Two related fixes:ScrollContentPresenter's bring-into-view used theDesiredSize-based viewport, which dropped requests coming from content stretched taller than it asks for instead of forwarding them to outer scrollers; andAutoSuggestBoxnow places its suggestion list in window coordinates, since the content can be offset.Given_InputPanenow covers a side panel that starts near the keyboard, a field outside anyScrollViewer, focus moving while the keyboard is up, hit-testing after the content moves, restoring the content when the keyboard hides, and an app that handlesShowingitself.Given_ScrollViewercovers the nested stretched-content case. Both fail without the fix. The change was also checked manually on an iPad in Safari with theSoftKeyboardFocusTestssample, whose steps are updated for the new behavior.PR Checklist ✅
Screenshots Compare Test Runresults.