UX: Prevent HorizontalOverflowNav component from scrolling viewport
#36715
Conversation
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
Whenever the `HorizontalOverflowNav` component is rendered, we call the `scrollIntoView` on the current active element to ensure that the link which is currently active will be shown to the user. However, we were calling `scrollIntoView` with the `container` option defaulting to `all` which impacts all scrollable containers. Per mozilla docs, > All scrollable containers are impacted (including the viewport). This is not ideal as it can cause unintended scrolls on the viewport when there are other scrollable containers on the user's screen thus resulting in a bad UX. To resolve this, this commit adds the `container: "nearest"` option when we call `scrollIntoView` which ensures that only the nearest scrollable container to the active element is impacted. This problem was discovered while I was looking at review queue index page and noticed that my scroll position was always lost when new reviewable items are added to the page. It turns out that the review queue index page renders the `reviewable-refresh/item.gjs` component which then renders the `horizontal-overflow-nav.gjs` component.
Contributor
Author
Reviewer notesBefore
After
|
tgxworld
commented
Dec 16, 2025
| activeElement?.scrollIntoView({ | ||
| block: "nearest", | ||
| inline: "center", | ||
| container: "nearest", |
Contributor
Author
There was a problem hiding this comment.
See https://developer.mozilla.org/en-US/docs/Web/API/Element/scrollIntoView#container for the list of options.
KrisKotlarek
approved these changes
Dec 16, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Whenever the
HorizontalOverflowNavcomponent is rendered, we callscrollIntoViewon the current active element to ensure that the linkwhich is currently active will be shown to the user. However, we were
calling
scrollIntoViewwith thecontaineroption defaulting toallwhich impacts all scrollable containers.
Per mozilla docs,
This is not ideal as it can cause unintended scrolls on the viewport thus resulting in a bad UX. To resolve this, this commit adds the
container: "nearest"option when we callscrollIntoViewwhich ensures that only the nearest scrollable container to the active element is impacted.This problem was discovered while I was looking at review queue index
page and noticed that my scroll position was always lost when new
reviewable items are added to the page. It turns out that the review
queue index page renders the
reviewable-refresh/item.gjscomponentwhich then renders the
horizontal-overflow-nav.gjscomponent.