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

Support input scroll-into-view #820

Open
luxaritas opened this issue Aug 30, 2024 · 0 comments
Open

Support input scroll-into-view #820

luxaritas opened this issue Aug 30, 2024 · 0 comments
Labels
priority: p3/standard Enhancement with nominal value or bug with nominal impact size: md type: enhancement New feature or request

Comments

@luxaritas
Copy link
Member

Describe your idea

If you focus on an input that is not visible (or would place your cursor in a location that is not visible) when that input is in a region which can be scrolled (eg, a ScrollContainer, like in the design browser when a field is partially outside of the visible region), it should be scrolled into view.

Motivation

This mirrors browser behavior and is in general an accessibility feature. This is important for a keyboard user who might tab to a field, and is just generally useful as if you write in a text input, you want to be able to see what you're writing

Proposed Solution

Initially this appears straightforward - in the case of ScrollContainer, set the html wrapper to overflow: hidden so that element is the one that gets scrolled, listen for the scroll event, then reset the scroll position and instead offset the scroll container by that amount (nb: would need to update everywhere we use scroll thumbs to be able to update themselves when the scroll container itself triggers a scroll). However this doesn't quite work since the wrapper covers the entire area of the canvas, not just the visible area - we rely on clip-path for that. But we can't just change the wrapper to use a position and width/height, because DOMObjects rely on being able to generate a transform matrix relative to the canvas, but this would cause the underlying html element to have a transform relative to the scroll container position instead. (Additionally, if we did something silly like rotating or skewing an input, this wouldn't account for that, though to be honest we probably want to actively avoid that).

Other Information

See #819 for where this initially came up

@luxaritas luxaritas added type: enhancement New feature or request priority: p3/standard Enhancement with nominal value or bug with nominal impact size: md labels Aug 30, 2024
@github-project-automation github-project-automation bot moved this to Todo in Roadmap Aug 30, 2024
luxaritas added a commit that referenced this issue Aug 30, 2024
## Summary
Currently if you eg have the sequence field in the design browser part
way offscreen and then paste a long sequence, if will cause the entire
page to shift offscreen. This prevents that from happening

## Implementation Notes
By default, browsers move the page so that a focused input (and more
specifically, your cursor) is in view. This makes sense, as you want to
make sure you see what you're doing, and a keyboard user may be tabbing
through input fields which should scroll into view, etc. However: a)
scrolling the page is not actually what we want - we haven't actually
drawn content there that's just sitting offscreen, it's only "virtually"
in our scene and we'd actually need to redraw the scene and b) we have
overflow: hidden on our root game element, which means that there is no
good way to scroll the content back into view. Additionally, it may be
in a ScrollContainer which has it clipped, which means it may not even
show the input at all.

Arguably in some situations we should find a way to implement this
behavior - eg, in a scroll container, we should just scroll the scroll
container. However this is nontrivial, so will leave this to a future
enhancement and limit this work to fixing the buggy behavior. See #820.

This patch also removes the input masking hack since we no longer need
to support the misbehaving WebKit version, and that was getting in the
way of debugging this issue.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority: p3/standard Enhancement with nominal value or bug with nominal impact size: md type: enhancement New feature or request
Projects
Status: Todo
Development

No branches or pull requests

1 participant