Current behavior

On wide viewports (min-width: 1199px), SideInfoPanel is sticky (position: sticky; top: 0; align-self: flex-start) and intentionally shares the page scroller — no max-height / inner scrollbar (see issue #2909). Overlay mode (narrow viewports and .hide-side-info) already scrolls via div.side-info > .body { overflow: auto } with the panel stretched top: 0; bottom: 0.

When sticky content is taller than the visible area, the bottom is clipped while the pane is stuck — that matches this report.

Caveat on the suggested CSS: bare max-height: 100vh is a poor fit here. Sticky top: 0 is relative to .autofit, which already sits below the fixed topbar, so 100vh overshoots the available height.

Provisional implementation plan

1. Change only the wide/sticky rules in side-info.css (overlay already scrolls).
2. Cap open sticky panel height to the sticky scrollport (prefer a height tied to .autofit / containing block — not raw 100vh).
3. Put overflow on the chosen scroll region (whole panel vs .body only — see Q1).
4. Keep closed-state rules (max-height: 0, overflow: hidden, etc.) intact so collapse animation/behavior stays correct.
5. Verify on issue / PR / build / pack detail (and board card detail if applicable) at wide width with tall side content; confirm overlay / breakpoint behavior unchanged.
6. Expect CSS-only unless measured height against topbar/autofit proves necessary.

Implementation is blocked on the clarifying choices below.

Clarifying questions

1. Where should the scrollbar live?

• A. Entire sticky panel scrolls (header + body)
• B. Only .body scrolls; header (title/close) stays pinned — same as overlay mode
• C. Keep sharing page scroll only; do not add an inner scrollbar (reject the suggested approach)

2. How should max height be computed?

• A. max-height: 100vh as suggested
• B. Cap to the sticky containing block / autofit viewport (e.g. max-height: 100% or equivalent relative to .autofit)
• C. Explicit chrome offset, e.g. max-height: calc(100vh - <topbar>) / 100dvh

3. Nested scroll UX (page + side panel)?

• A. Accept dual scrollers when side content overflows
• B. Make the sticky panel fill the viewport and primarily scroll internally
• C. Enable inner scroll only when content would otherwise clip (dynamic / JS)

4. Change scope?

• A. Shared sticky rules in side-info.css only (all SideInfoPanel pages on wide viewports); leave overlay CSS unchanged
• B. Per-page overrides only where content is known to be tall
• C. Also revisit / change overlay scrolling behavior

Please reply with choices (e.g. 1B, 2B, 3A, 4A) or alternatives, and we can proceed to implementation from there.

There should only be one visible scroll bar, which is the main scroll bar. The side panel should scroll up and down with the main scroll bar. Any scrolling activity on the page should first scroll the side panel to its limit and then scroll the main page.

This ensures that we only have a single scroll gesture with a highly positive UX

@servicedesk

@zaakiy Thanks — that clarifies the intent, and it matches the sidebar-first linked scroll option discussed in issue #2908 (then called 3D), which was deferred when we shipped the simpler sticky + shared page scroll design in issue #2909.

Interpretation

So this is not a small CSS tweak (max-height + overflow-y: auto). Current sticky behavior (issue #2909) already gives one scroller and no inner bar; the remaining gap for tall side content is exactly the missing sidebar-first priority.

Updated implementation plan

1. Keep today’s wide-viewport sticky foundation (side-info.css: sticky under .autofit / top chrome, natural height, no inner scrollbar; overlay / .hide-side-info unchanged).
2. Add sidebar-first scroll coordination in side-info.js for wide/sticky mode only:
   • On wheel / trackpad / keyboard scroll while the sticky pane is in play, apply delta to the side panel first (via 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 the priority when scrolling up.
3. Short side content: keep current sticky “pin under top chrome while main scrolls” behavior (no-op for the linker when the pane fits the viewport).
4. Tall side content: lower fields become reachable via the same main scrollbar / gesture, without a second visible bar.
5. Scope: shared sticky path for all SideInfoPanel pages (issue / PR / build / pack); do not change overlay scrolling.
6. QA focus: tall vs short side content; wheel, trackpad inertia, and keyboard; open/close / resize / breakpoint; confirm overlay mode unchanged.

Caveat

With true sidebar-first linking, the visible scrollbar still tracks the main .autofit scroll position. Early gesture motion may move only the side panel while the thumb stays put — that is inherent to “one bar + sidebar priority,” not a bug. If that feels wrong in practice, we would revisit (but that would trade off one of the constraints above).

Next step

If this plan matches what you want, reply to confirm and we will open a fresh Improvement issue for implementation (same pattern as issue #2908 → issue #2909) and close this Question.

If you would rather take a simpler CSS-only compromise instead (still one scrollbar, tall pane reveals as the page scrolls, but not strict “sidebar first then main”), say so and we can outline that smaller plan instead.

@servicedesk confirming that this plan matches what I wanted.

Closing as answered; implementation tracked in issue #2994.

@zaakiy Created implementation issue #2994 with the agreed design:

• Sticky foundation unchanged; no inner scrollbar on the side pane
• Sidebar-first linked scroll for wide/sticky mode (side-info.js)
• Short side content keeps today’s sticky behavior; tall content is reachable via a single scroll gesture
• Narrow / .hide-side-info overlay unchanged

Closing this Question as answered.