[🐛 Bug]: Alert detail Timeline cannot be scrolled with mouse wheel / trackpad

[franciscocpg]

Describe the bug

In the alert detail side panel, the Timeline section is clipped to 500px but cannot be scrolled with the mouse wheel or trackpad, so entries below the fold are unreachable. On my instance 658px out of 1158px of timeline content was hidden.

The container itself is fine: setting scrollTop programmatically works and sticks. The problem is that the wheel gesture never reaches it.

Root cause

react-chrono renders a large number of nested scroll containers (overflow: auto / overflow: hidden) that have zero scroll extent — including TimelineContentDetailsWrapper, which is the element directly under the cursor. Chrome latches the wheel gesture onto the nearest scroll container from the hit test; since that container and everything above it up to the card have no scrollable extent, the gesture is consumed and never chains to the tremor-Card-root that actually has the 658px of extent.

Measurements taken on a live instance (Chrome DevTools + scripted wheel events):

• card.scrollTop = 300 → sticks (still 300 after 150ms and after 1.65s), so the card is scrollable
• Card computed style: max-height: 500px, overflow-y: auto; content height 1158px → 658px hidden
• Real wheel over the Timeline: the event is delivered (deltaY: 300) but with cancelable: false, and no element in the document emits a scroll event
• No preventDefault() anywhere in the ancestor chain (defaultPrevented: false at every level)
• scrollIntoView and scrollTo patched on Element.prototype: never called
• Element under the cursor: TimelineContentDetailsWrapper, overflow-y: auto, real max scroll extent 0. Roughly 428 such zero-extent scroll containers exist inside the card
• Wheel with the cursor outside the chrono subtree (e.g. over Description) scrolls the side panel normally to its full extent (728px)

Confirmed by inverting it: forcing overflow: visible on those wrappers makes wheel scrolling work immediately (scrollTop observed going 0 → 400 → 658).

Note: removing max-h-[500px] from the Card alone does not fix it. I tested that — the card then grows to its full height and the side panel gains 2043px of scroll extent, but the gesture is still swallowed inside the react-chrono subtree.

To Reproduce

1. Have an alert with enough timeline entries to exceed 500px of height (a handful of workflow enrichment entries is enough)
2. Click the alert in the feed to open the detail side panel
3. Put the cursor over the Timeline area and scroll with a mouse wheel or trackpad
4. Nothing scrolls; the entries below the fold cannot be reached

Expected behavior

Wheel/trackpad over the Timeline should scroll the timeline, or chain to the side panel.

Screenshots

Screen recording attached below.

Workaround

div[class*="TimelineContentDetailsWrapper"],
div[class*="TimelineMainWrapper"] { overflow: visible !important; }

Suggested fix

Give react-chrono a bounded height so that its own scroll container owns the overflow, instead of clipping it from the outside with the card's max-height. Alternatively, remove the zero-extent overflow from the chrono wrappers so the gesture can chain to the card.

Additional context

Secondary issue, only visible once scrolling works: the periodic alert refresh resets scrollTop to 0, so the reading position is lost mid-scroll.

Related: #4618 reports the same class of problem on the incident timeline (closed without a fix). Interestingly the bot reply there already pointed at the max-h-[500px] overflow-y-auto card, which matches what I measured.

Environment

• Keep 0.54.2, self-hosted on Kubernetes via the keephq/keep Helm chart (chart version 0.1.96)
• Chrome on macOS

[dosubot]

Hi @franciscocpg! I'm Dosu and I'm helping the Keep team.

Excellent write-up — the root cause you diagnosed lines up exactly with the code. The Timeline card is <Card className="max-h-[500px] overflow-y-auto p-0"> wrapping a react-chrono <Chrono> in VERTICAL mode with no bounded height of its own [1], so the outer card clips content that chrono's nested wrappers never actually need to scroll — exactly the zero-extent scroll-container situation you measured.

This is the same pattern flagged in #4618: that report hit the same max-h-[500px] overflow-y-auto Card wrapping a Chrono instance, and the reply there pointed at that card without a real fix [2]. So this has resurfaced rather than been resolved.

On your secondary point about scrollTop resetting during refresh: the AlertTimeline component is rendered with key={auditData ? auditData.length : 1} [3], which forces React to remount the entire Chrono tree (and thus reset native scroll position) any time the number of audit entries changes. The refresh button itself just calls mutate() on the useAlertAudit SWR hook [4], so if the fetch returns even one new entry, the key changes and the component remounts — that's a plausible mechanism for the scroll reset you observed.

Your suggested fixes (bound react-chrono's own height so it owns the scroll, or strip the zero-extent overflow off the chrono wrappers) both look like the right direction. There's no special height/overflow configuration wired up for Chrono beyond cardHeight="auto" and the classNames overrides currently in the file [5], so nothing else in the code compensates for the outer clipping today.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[breken-ai]

@franciscocpg Confirmed the root cause: react-chrono renders nested overflow containers with zero scroll extent, and Chrome latches wheel gestures onto the one under the cursor instead of chaining to the clipped timeline container - that is why the wheel does nothing. Fix in #6805: the scroll container becomes a plain inner div with a non-passive wheel listener that scrolls it directly and only calls preventDefault when the position actually changed, so overscroll still chains to the page. Verified in real Chrome: wheel over the timeline scrolls per gesture, and at max scroll the event passes through untouched.

Built by breken, your AI support engineer - breken.ai finds the bug, proves the fix with unmatched RCA, answers customers in your voice, and keeps your code and support docs clean - this one's on us.