-
-
Notifications
You must be signed in to change notification settings - Fork 3.4k
dom: Focus scroll to the element only if it is not visible #40447
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
Conversation
aa9f596 to
f382e2b
Compare
|
🔨 Triggering try run (#19129788987) for Linux (WPT) |
f382e2b to
3571e8c
Compare
|
Test results for linux-wpt from try job (#19129788987): Flaky unexpected result (42)
Stable unexpected results that are known to be intermittent (27)
Stable unexpected results (2)
|
|
|
|
Test |
3571e8c to
9ca91f2
Compare
Signed-off-by: Jo Steven Novaryo <steven.novaryo@gmail.com>
9ca91f2 to
0ea4967
Compare
|
Updated the WPT result, and tracking issues for selection |
| // We are following the firefox implementation where we are only scrolling to the element | ||
| // if the element itself it not visible. | ||
| let scroll_axis = ScrollAxisState { | ||
| position: ScrollLogicalPosition::Center, | ||
| requirement: ScrollRequirement::IfNotVisible, | ||
| }; | ||
|
|
||
| // TODO(stevennovaryo): we doesn't differentiate focus operation from script and from user | ||
| // for a scroll yet. | ||
| // TODO(#40474): Implement specific ScrollIntoView for a selection of text control element. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of making all the conceptual changes to scroll_into_view_with_options, would it be possible to first just check if the element is already visible and not call scroll_into_view_with_options?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It should be possible, if we are still maintaining the behavior where we just compare the clip rectangle of scroll container ancestor to it's target element, I think we might end-up iterating the same element with the same queries. I would be glad to hear about the concern for this behavior. For now we are following the Mozilla's behavior for this one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you mean by iterating the same element with the same queries? Running this query twice shouldn't be a problem, as the translation will be cached the first time and the second time it will be a single matrix multiplication. I think this will greatly simplify the change if you wouldn't mind just doing that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand the idea. I just want to checkout that we have considered a same concern.
I just afraid that we will duplicate a lot of codes in the iteration and the calculation the dimension of container and it's target rectangle, not to mention that the scroll_into_view_with_options is not complete (e.g. no writing modes). Additionally, we would also have slight difference in how it would behave compared to Firefox, but I am not sure this would be relevant.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can't you just calculate the result of getBoundingClientRect(), check to see if it is fully enclosed by the viewport, and, if so, return early?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure that the desirable way to check the visibility is to only check for the viewport. Following the behavior of ScrollIntoView, that iterates through the scroll container, checking whether a element is visible relative to each scroll container that contains its should be more reasonable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of making all the conceptual changes to
scroll_into_view_with_options, would it be possible to first just check if the element is already visible and not callscroll_into_view_with_options?
I kinda agree. Because we sometimes we want to scroll_into_view_with_options without caring about whether the target is visible or not.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be ok. As we pass the check-visibility-or-not flag to scroll_into_view_with_options now.
yezhizhen
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is nice. But I'm curious about the motivation of the change, if this is implementation defined.
| // box start edge and scrolling box end edge or an invalid situation: Do nothing. | ||
| else { | ||
| current_scroll_offset | ||
| 0. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suppose this fixes a bug not mentioned?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added in PR description and a WPT test for the bug.
| ScrollRequirement::IfNotVisible => { | ||
| // Because the element_start and element_end have taken into account the scroll_offset, the | ||
| // viewport_start and viewport_end should have the root coordinate space. | ||
| let viewport_start = 0.; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the container always Viewport? Would it be possible that this is Element?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is quite not descriptive for me as well. I have changed it to be a scrollport for now. Let me know if there is a better suggestion.
| // We are following the firefox implementation where we are only scrolling to the element | ||
| // if the element itself it not visible. | ||
| let scroll_axis = ScrollAxisState { | ||
| position: ScrollLogicalPosition::Center, | ||
| requirement: ScrollRequirement::IfNotVisible, | ||
| }; | ||
|
|
||
| // TODO(stevennovaryo): we doesn't differentiate focus operation from script and from user | ||
| // for a scroll yet. | ||
| // TODO(#40474): Implement specific ScrollIntoView for a selection of text control element. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of making all the conceptual changes to
scroll_into_view_with_options, would it be possible to first just check if the element is already visible and not callscroll_into_view_with_options?
I kinda agree. Because we sometimes we want to scroll_into_view_with_options without caring about whether the target is visible or not.
|
🤖 Opened new upstream WPT pull request (web-platform-tests/wpt#56254) with upstreamable changes. |
|
✍ Updated existing upstream WPT pull request (web-platform-tests/wpt#56254) title and body. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Testing: Private WPT since this is implementation defined.
In the end, we added a new public WPT as well :)
| <!DOCTYPE html> | ||
| <html> | ||
| <head> | ||
| <title>scrollIntoView called on the descendant of shadow host with a slot should treat the slot as a pontential scroll container</title> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Btw we should change the title here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! I have changed the title and updated the description.
|
✍ Updated existing upstream WPT pull request (web-platform-tests/wpt#56254) title and body. |
16b2638 to
2c826ec
Compare
|
📝 Transplanted new upstreamable changes to existing upstream WPT pull request (web-platform-tests/wpt#56254). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| <title>scrollIntoView nearest shouldn't scroll a completely visible element</title> |
Typo.
|
📝 Transplanted new upstreamable changes to existing upstream WPT pull request (web-platform-tests/wpt#56254). |
Signed-off-by: Jo Steven Novaryo <steven.novaryo@gmail.com>
aa21517 to
e627520
Compare
|
📝 Transplanted new upstreamable changes to existing upstream WPT pull request (web-platform-tests/wpt#56254). |
Currently when we call a
Focuswe always scroll a focusable element to the center of the container. However, this would causes a different behavior where UAs wouldn't scroll when a focus is called to a visible element. This PR add implementations following the behavior of Firefox nsFocusManager::ScrollIntoView, where we are scrolling to the element if it is not visible.This would enhance the user experience of focusing an input element, where we should avoid moving the element if it is visible.
Incidentally fix a calculation bug for the calculation of
ScrollIntoViewwithnearestblock or inline option.Testing: Private WPT for the implementation defined behavior and public WPT for the bug.