feat: add sticky inputs section to gaps and timeline pages

[eran132]

Re-submitted from upstream branch (previously #1513).

Summary

Created reusable StickyInputs component. Applied to gaps and timeline pages.

Closes #1059

Test plan

• TypeScript compiles clean
• ESLint passes
• Unit tests pass (9/9)
• CI checks pass

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

Adds a reusable sticky header wrapper for input controls and applies it to the Gaps and Historic Timeline pages so the filters remain visible while scrolling.

Changes:

• Created a reusable StickyInputs styled-component wrapper.
• Wrapped the input/filter sections on the historic timeline and gaps pages with StickyInputs.
• Adjusted layout structure so only the input section is sticky while results/content scroll.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

File	Description
src/pages/historicTimeline/index.tsx	Wrapes the filter inputs in StickyInputs to keep them visible while scrolling the timeline content.
src/pages/gaps/index.tsx	Wrapes the filter inputs in StickyInputs so filters stay visible above the gaps table.
src/pages/components/StickyInputs.tsx	Introduces the reusable sticky wrapper component (positioning, layering, background).

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Import style for StickyInputs is inconsistent across pages: this file uses an absolute src/... import while src/pages/gaps/index.tsx uses a relative ../components/StickyInputs. Standardizing on one convention improves consistency and avoids path-alias-only builds causing import churn (and can prevent accidental duplicate module instances in some setups).

Suggested change

	import { StickyInputs } from 'src/pages/components/StickyInputs'
	import { StickyInputs } from '../components/StickyInputs'

[Copilot]

The z-index: 100 and padding-bottom: 8px are hard-coded magic numbers. Consider deriving these from the app/theme system (e.g., theme spacing and z-index scale) so stacking and spacing stay consistent across pages and don’t require manual tuning when global layout changes.

Suggested change

	z-index: 100;
	background: inherit;
	padding-bottom: 8px;
	z-index: var(--z-index-sticky-inputs, 100);
	background: inherit;
	padding-bottom: var(--spacing-sticky-inputs-bottom, 8px);

[Copilot]

background: inherit can resolve to transparent if the parent doesn’t set a background, which can reduce contrast/readability when the sticky section overlays scrolling content. Prefer setting an explicit background color (typically the page/surface background from the theme) and optionally a subtle border/shadow to clearly separate the sticky inputs from the content underneath.

Suggested change

	background: inherit;
	background: #fff;
	border-bottom: 1px solid rgba(0, 0, 0, 0.08);

[github-actions]

Preview: https://s3.amazonaws.com/noam-gaash.co.il/27060490177/open-bus/2251/index.html
Preview Storybook: https://s3.amazonaws.com/noam-gaash.co.il/27060490177/open-bus/2251/storybook/index.html
Test Report (if available): 'https://s3.amazonaws.com/noam-gaash.co.il/27060490177/open-bus/27fba877f482ee7dbc4aef3d79aec56de3e52bde/test-results/index.html'

[NoamGaash]

Please verify (human) that the new layout looks good - this issue is about appearance and user experience

[eran132]

@NoamGaash — verified the layout manually as you asked, and good thing I did: while testing the scroll behavior with real data loaded on both /timeline and /gaps, I found the pinned inputs had a transparent background (background: inherit resolved to transparent because PageContainer has no background). Scrolling results bled straight through the inputs and made them unreadable — in both light and dark mode.

Fixed in 7261786: StickyInputs now uses the MUI theme's palette.background.default (the same color ScopedCssBaseline paints the page), so the sticky bar is opaque and theme-correct.

Verified after the fix, both pages, both themes, RTL:

• Inputs stay pinned at top while results scroll underneath ✅
• Solid background, no bleed-through, fully readable ✅
• Light + dark both clean ✅

Also rebased on main — there was a conflict in historicTimeline/index.tsx (main refactored the timestamp logic to .startOf('minute') and removed a StyledTimelineBoard reference that was never defined). Kept main's newer logic + the imported TimelineBoard.

tsc + eslint + tests all green. Re-requesting review.

[NoamGaash]

thank you! looks great

[eran132]

Resolved the conflict with main (commit 11b0992). Main had refactored the timeline + gaps pages substantially (new `date`/`timeOfDay` state, timezone-aware `dayjs.tz(date, ISRAEL_TIMEZONE)`, `?? undefined` null-safety, `search.stopKey` from context, new computed `time` for `TimelineBoard`). I kept the `` wrapper around the input rows, adopted all of main's improvements inside it, and kept the hits-timeline outside the wrapper so results still scroll under the pinned bar (the whole point of this PR).

Net diff vs current main is still small and focused: 3 files (+162/-141) — `StickyInputs.tsx`, `gaps/index.tsx`, `historicTimeline/index.tsx`.

Verified: `tsc` ✅, full lint ✅, unit tests 64/64 ✅, plus Playwright + visual review of sticky-scroll behavior on timeline (light + dark) and gaps (light) — inputs stay pinned at top with opaque themed background (the bug fixed earlier in this PR), results scroll cleanly underneath, all inputs populate correctly with main's new state shape.

[NoamGaash]

seems like there are few visual regressions

[eran132]

@NoamGaash you were right — there was a real regression. Investigated and fixed in 27fba87.

What was wrong: the always-opaque sticky bar (which I'd added earlier to stop scrolling timeline content from bleeding through it) was being painted with theme.palette.background.default. On the gaps page that color doesn't exactly match the surrounding PageContainer area, so at rest the input section showed up as a faint container box — clearly visible in dark mode against the near-black page. On the timeline page it happens to match, which is why I missed it in my own visual check.

The fix: conditional opacity. The bar is transparent at rest, becomes opaque only when its scrollable ancestor has actually scrolled (scrollTop > 0). The two requirements are opposite by nature:

• At rest there's nothing behind the bar to hide — transparency guarantees zero visual diff vs main on any page, regardless of which container surrounds it
• Scrolled, content IS behind it — opacity is needed to stop the bleed-through (the bug we fixed earlier)

Detection walks up the DOM for the nearest scrollable ancestor (overflow-y auto/scroll/overlay) and listens to its scroll event. Works for this codebase's inner-scrollable layout; falls back to window scroll if no inner scroller is found.

Verified locally (via my own Playwright + frame inspection, since I don't have Applitools access):

• At-rest gaps-dark is now pixel-identical to main — no visible container box
• Scrolled timeline-dark has solid opaque bg — station name חיים הרצוג/שדרות מנחם בגין (גדרה) reads cleanly with no timeline timestamps bleeding through it
• Playwright assertion: data-stuck === 'true' after wheel-scroll (deterministic, not just visual)

Re-requesting review. Applitools should also be happy this time — at-rest baselines should match. Let me know if the diffs look right on your end.

[NoamGaash]

what's your email address? I'll add you.
I think that the Eyes dashboard is public, so you should have read-only permissions even without me adding you (tho I do want to add you so you'll be able to execute and accept new baselines)