Add sidebar-first linked scroll for tall SideInfoPanel content (OD-2994)

Add sidebar-first linked scroll for tall SideInfoPanel content #2994

Service Desk opened 1 day ago

Summary

On wide viewports, keep a single visible scrollbar (the main .autofit scroller) while making tall SideInfoPanel content fully reachable: coordinate scroll so the side panel moves to its limit first, then the main page. Do not add an inner scrollbar on the side pane.

Design agreed in issue #2992.

Background

Issue #2909 shipped CSS position: sticky with shared page scroll and no inner scrollbar. That left tall side content awkward to reach while stuck. Sidebar-first linked scroll was considered in issue #2908 (option 3D) and deferred; issue #2992 confirmed it as the desired UX.

Scope

All detail pages that use SideInfoPanel:

Issues
Pull requests
Builds
Packs

Keep today’s fixed overlay behavior below the 1199px breakpoint and on pages with .hide-side-info.

Behavior (wide viewports, ≥1199px)

Keep sticky foundation — existing sticky under .autofit / top chrome, natural height, no max-height / overflow: auto on the pane.
One visible scrollbar — only the main page scroller; no nested bar on the side pane.
Sidebar-first linked scroll — on wheel / trackpad / keyboard scroll while sticky mode is active:
- Apply delta to the side panel first (offset / translate within the sticky viewport) until it hits its top or bottom limit.
- Pass remaining delta to the main .autofit scroller so the page moves only after the side panel cannot move further.
- Reverse priority when scrolling up.
Short side content — keep current sticky “pin under top chrome while main scrolls” (linker is a no-op when the pane fits the viewport).
Tall side content — lower fields become reachable via the same main scrollbar / gesture.

Implementation notes

Prefer coordination in side-info.js for wide/sticky mode only; leave overlay / .hide-side-info scrolling unchanged.
Shared sticky path in side-info.css should remain without an inner scrollbar.
Expect the scrollbar thumb to track .autofit position; early gesture motion may move only the side panel while the thumb stays put — that is inherent to one bar + sidebar priority.
Verify wheel, trackpad inertia, keyboard, open/close, resize, and breakpoint transitions across issue / PR / build / pack detail.

Acceptance

On wide viewports, only one visible scrollbar (main page).
Tall side content is reachable by scrolling the side panel to its limit first, then the main page, in a single scroll gesture.
Short side content keeps today’s sticky behavior.
No nested scrollbar inside the side pane.
Narrow / .hide-side-info overlay behavior unchanged.
Works on issue, PR, build, and pack detail pages that use SideInfoPanel.

Related: issue #2992 (also issue #2908 / issue #2909 for prior sticky work).

Copy

Related
- Question about adding scroll capability to the site info panel (OD-2992) Closed

Activities

Service Desk referenced from other issue 1 day ago

Question about adding scroll capability to the site info panel (OD-2992)

Closed
Robin Shen commented 22 hours ago

@zaakiy I think that all purpose of sidebar sticky is to make important information visible. Information on sidebar is organized from top to down based on the importance. Scrolling sidebar to make most important information invisible while scrolling the page defeats this purpose.

Copy
Zak Siddiqui commented 16 hours ago
@robin my motivation is to make both the sidebar and the main page scrollable at the same time.

Meaning there should only be one scroll region, not two.

However, within that scroll region, we need the flexibility of being able to scroll both the sidebar and the main page.

There are two scenarios here in the wide view.

Sidebar is longer than the main page. In this case, we need the issue to scroll the sidebar.

Main page is longer than the sidebar, but the sidebar is cropped. In this case, what is currently happening is that the main page is scrolling, and the sidebar is cropped, and you lose out on the bottom portion of the sidebar.

In the case of the second scenario, what we want to be able to do is to scroll the sidebar.

However, what we do not want is that we have two separate scroll regions.

Meaning we don't want users to need to move the mouse over to the sidebar and move the mouse over to the main page. Instead, the user should be able to scroll anywhere on the page, whether it be on the sidebar or on the main page, and the behavior is uniform.

In order to achieve this, what we should do is put the scrolling priority on the sidebar, since it is almost always shorter than the main page. It's a couple of hundred pixels at best that is scrolled, and then the main page is scrolled. This is what I'm trying to achieve with this issue.

Copy
Robin Shen commented 15 hours ago

I think we seldomly need to scroll to bottom of the sidebar, as information there is assumed to be rarely accessed. And in case we do need that, just scroll main page to bottom, and this is normal behavior of side sticky.

Copy
Zak Siddiqui commented 15 hours ago

No, I'm pretty sure there was a scenario where the sidebar couldn't be scrolled down. It was an edge case. I'll find it and come back.

Copy
Robin Shen commented 15 hours ago

Then that is definitely a bug, please help to find that case.

Copy
Zak Siddiqui commented 15 hours ago

@robin I'm happy to say that I could not reproduce the bug.

It may be an extreme edge case.

I would be happy for you to close this issue

And then I will document the bug later when I find it. (If it still exists)

Copy
Robin Shen changed state to 'Closed' 15 hours ago
Previous Value Current Value
Open

Closed
Zak Siddiqui commented 12 hours ago

@robin I found the edge case.

See screenshot below.

There is another one though

Copy
Zak Siddiqui changed state to 'Open' 12 hours ago
Previous Value Current Value
Closed

Open
Login to comment

Previous Value	Current Value
Open	Closed

Previous Value	Current Value
Closed	Open

Type	Improvement
Priority	Normal
Assignee	Robin Shen
Labels	No labels

Issue Votes (0)

Watchers (3)

Reference

OD-2994