Investigation

On wide viewports (≥1199px), div.side-info is an in-flow flex sibling of the main content inside .card-body (SideInfoPanel / side-info.css). Scrolling happens in the page’s .autofit container, so the pane’s header/fields scroll away with the page while the right column still occupies width — that is the empty space you are seeing.

On narrow viewports (≤1198px) and on pages with .hide-side-info (e.g. PR changes), the pane is already position: fixed (full-height overlay drawer). So the gap only shows up in the wide “pinned” layout used on issue / PR / build / pack detail pages.

The “stick after scroll” behavior you described is exactly CSS position: sticky (scrolls normally until it hits the top of the scrollport, then stays). That is feasible here, but sticky is blocked by overflow: hidden on ancestors — issue detail currently has that on both .card and .card-body, so those would need adjusting if we go sticky.

Options

A. Keep current behavior (no change)

• Pros: No risk of regression; matches today’s layout.
• Cons: Wide screens keep the empty right column when scrolled; side fields are harder to reach.

B. Always fixed on wide viewports (reuse the existing overlay-style fixed pane, possibly still reserving the 360px column)

• Pros: Side info always visible; largely reuses current mobile/overlay CSS/JS; straightforward.
• Cons: Pane never sits in normal document flow at the top; tall side content needs its own internal scroll; can feel more “drawer-like” than a sidebar; careful handling of top chrome / z-index.

C. Sticky sidebar on wide viewports (position: sticky; top: …, with align-self: flex-start, max-height + internal scroll when content is taller than the viewport)

• Pros: Matches your preferred UX — in place at top, then sticks while scrolling; column width stays useful.
• Cons: Needs ancestor overflow fixes (at least on issue detail); sticky + flex has more edge cases (short vs tall side content, nested scrollers); slightly more testing across issue/PR/build/pack pages.

D. Hybrid — sticky while the detail card is in view; if side content is very tall, fall back to internal scrolling (and/or keep today’s full fixed overlay below the breakpoint)

• Pros: Best of C with safer handling when the pane is taller than the viewport.
• Cons: Most complex; more CSS/JS and QA.

Recommendation

C (sticky on wide viewports), keeping today’s fixed overlay below 1199px / .hide-side-info. That matches the UX you described and keeps the existing mobile behavior. Pair it with max-height + overflow: auto on the side body so long metadata lists remain usable.

If you prefer minimal change and “always visible” over “sticks after scroll”, choose B.

Clarifying questions

1. Scope — which pages should change?
   A. All detail pages that use SideInfoPanel (issues, PRs, builds, packs)
   B. Issues only
   C. Issues + PRs only

2. Desired wide-viewport behavior?
   A. Sticky (option C — recommended)
   B. Always fixed (option B)
   C. Hybrid (option D)
   D. Leave as-is for now (option A)

3. When side-info content is taller than the viewport?
   A. Internal scroll inside the pane (recommended)
   B. Allow the pane to grow and scroll away again after the sticky range
   C. No preference

4. Should the sticky/fixed top offset sit under any top UI chrome, or flush to the scrollport top (similar to today’s mobile overlay at top: 0)?
   A. Flush to scrollport top
   B. Offset below top chrome if applicable
   C. No preference

Reply with choices (e.g. 1A, 2A, 3A, 4A) and we can turn this into an implementation issue / change.

@servicedesk

1. a
2. A. Sticky (option C — recommended), but we don't want an internal scroll. It should, it should scroll naturally as the page scrolls. Perhaps what we could do is when the scroll action is performed, we prioritize the sidebar to go up or down and then when the sidebar reaches its limit, Then we can scroll the main page.
3. please elaborate on option B.
4. b

@zaakiy Thanks — recorded so far:

1. A — all detail pages that use SideInfoPanel (issues, PRs, builds, packs)
2. Sticky on wide viewports
3. B — offset below top chrome

On (2)/(3) you asked for sticky without an inner scrollbar, and for scroll to prioritize the sidebar until it hits its limit, then scroll the main page. Those are related but not the same as plain CSS sticky, so here is the elaboration and a clearer choice.

Question 3 option B (elaborated)

B. Allow the pane to grow and scroll away again after the sticky range means: use position: sticky with the side pane at its natural full height — no max-height / overflow: auto inside the pane.

How it behaves:

• Side content shorter than the viewport: the pane sticks under the top chrome while the main column scrolls. Side fields stay visible. This matches the UX you originally described when metadata is short.
• Side content taller than the viewport: there is still only one page scroller (the same .autofit scroll container). Sticky tries to keep the top of the pane pinned, but because the pane is taller than the viewport, the lower side fields are clipped until further page scroll lets the sticky constraint release / move the pane within its containing block. Main content and sidebar move in one shared scroll stream — there is no “sidebar first, then main” priority.

Pros of B:

• No nested scrollbar; scrolling feels like normal page scroll
• Mostly CSS; fewer edge cases than custom scroll sync
• Works well when side content is usually shorter than the viewport

Cons of B:

• Very tall side panes can make lower fields awkward to reach while the top is stuck
• Does not implement the sidebar-first priority you described

What you described (sidebar-first)

“When scrolling, prioritize the sidebar; when it reaches its limit, then scroll the main page” is a linked sticky sidebar pattern. Pure CSS sticky does not do that. It usually needs a small amount of JS to sync wheel/trackpad movement with the two columns (and to reverse the priority when scrolling up).

For clarity, call that:

D. Sidebar-first linked scroll (JS)

• Scroll down: move/reveal the sidebar first until it cannot move further within the viewport; then continue scrolling the main column while the sidebar stays pinned at that limit.
• Scroll up: reverse — bring the sidebar back first, then the main column.
• Still no inner scrollbar on the side pane.

Pros of D:

• Closest to the behavior you described
• Tall side content stays reachable without a nested scrollbar

Cons of D:

• Needs JS; more edge cases (trackpad inertia, nested scrollers, the existing .autofit container)
• More QA across issue / PR / build / pack detail pages

Recommendation

Keep: sticky on wide viewports, all SideInfoPanel pages, offset under top chrome.

For tall content:

• Prefer 3B if “no inner scroll” is enough and shared page scroll is acceptable (simpler).
• Prefer 3D if sidebar-first priority is a hard requirement.

Please confirm tall-content choice with 3B or 3D (plus any tweak). Once that is settled we can turn this into an implementation change and close this Question.

@servicedesk

This sounds absolutely perfect!!!

Prefer 3B if “no inner scroll” is enough and shared page scroll is acceptable (simpler).

please generate a fresh issue with this design and close this issue.

test

Reopening after accidental close during state discovery.

Closing as answered; implementation tracked in #2909.

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

• Sticky on wide viewports for all SideInfoPanel pages (issues, PRs, builds, packs)
• No inner scrollbar; shared page scroll (option 3B)
• Offset below top chrome
• Narrow / .hide-side-info overlay unchanged

Closing this Question as answered. (Please ignore the earlier stray test comment — that was accidental while checking state transitions.)