Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bring control into view only if control isn't properly visible in viewport #18359

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

emmauss
Copy link
Contributor

@emmauss emmauss commented Mar 3, 2025

What does the pull request do?

Brings a control into view when request only if the control is currently not in the scrollviewer's viewport, or such that most of the child is visible in the viewport. Behavior was adapted from WPF's implementation. If the child is completely visible or contains the full viewport, no offset change is done.

What is the current behavior?

Requesting a child be brought into view will always align the top of the child to the top of the viewport, even if the child is fully visible. This forces the scroll offset to change reset even if the child is slightly moved into the viewport manually. This creates problems with focus, as for most focusable controls, they are brought into view on gaining focus. Focus is gained in multiple ways, most common of which is a toplevel activating after being deactivated.

What is the updated/expected behavior with this PR?

How was the solution implemented (if it's not obvious)?

Checklist

Breaking changes

Obsoletions / Deprecations

Fixed issues

Fixes #18252

@emmauss emmauss changed the title Bring control into view only if control isn't currently in viewport Bring control into view only if control isn't properly visible in viewport Mar 3, 2025
@emmauss emmauss requested review from MrJul and grokys March 3, 2025 11:15
@emmauss emmauss force-pushed the bring_focus branch 2 times, most recently from 5b20e5a to 92b15c6 Compare March 3, 2025 12:28
double childStart,
double childEnd)
{
// If child is above viewport, i.e. top of child is above viewport top and bottom of child is above viewport bottom.
Copy link
Member

Choose a reason for hiding this comment

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

Minor, but this comment should read is at least partially above the viewport, or something along those lines.
The variable naming (isChildAbove) initially made me think that this was checking whether the child was entirely outside the viewport, and the comment reinforced that idea.

(Same thing for isChildBelow)

@MrJul
Copy link
Member

MrJul commented Mar 5, 2025

This looks good, but I believe we need additional backing unit tests in this area, which are missing currently.

The following cases should be checked:

  • Child is fully in view (smaller than or equal to the viewport) ⇒ It doesn't move
  • Child is fully above ⇒ It's moved to the top of the viewport
  • Child is partially above (intersecting with the viewport) ⇒ It's moved to the top of the viewport
  • Child is fully below ⇒ It's moved to the bottom of the viewport
  • Child is partially below (intersecting with the viewport) ⇒ It's moved to the bottom of the viewport
  • Child is both partially above and partially below the viewport (it's too large to fit) ⇒ It doesn't move

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

ScrollViewer with SelectableTextBlock scrolls up when focus changes
2 participants