[PR #663] [MERGED] fix(renderer): fallback scroll events to focused renderable #1475

New issue

Closed

opened 2026-03-14 09:38:43 +03:00 by kerem · 0 comments

kerem commented

2026-03-14 09:38:43 +03:00

Owner

📋 Pull Request Information

Original PR: https://github.com/anomalyco/opentui/pull/663
Author: @remorses
Created: 2/10/2026
Status: ✅ Merged
Merged: 2/11/2026
Merged by: @kommander

Base: main ← Head: fix-scroll-fallback-focused-target

📝 Commits (3)

d73bd3b fix(renderer): fallback scroll events to focused renderable
1166999 fix: add .focused check to scroll fallback target and clarify test name
7ea7a2c Merge branch 'main' into fix-scroll-fallback-focused-target

📊 Changes

2 files changed (+43 additions, -5 deletions)

View changed files

📝 packages/core/src/renderer.ts (+11 -4)
📝 packages/core/src/tests/renderer.mouse.test.ts (+32 -1)

📄 Description

Why

I hit this while testing critique: mouse-wheel scrolling was not working reliably in the main diff scrollbox unless the pointer happened to be over a hit-tested renderable cell. That made the scrollbox feel broken in normal usage.

Problem

For wheel events, renderer mouse handling currently consumes scroll input even when hit-testing returns no renderable target. In that case, no onMouseScroll handler runs, so focused scroll containers can appear unresponsive.

Fix

I kept existing hit-test dispatch and added a fallback target:

if hit-test finds a renderable, dispatch there (existing behavior)
if hit-test misses, dispatch to the currently focused renderable (new behavior)

This preserves current semantics while making wheel input reach the active scroll container when the pointer is over non-hit-tested cells.

Validation

I added a regression test in packages/core/src/tests/renderer.mouse.test.ts that verifies scroll events outside hit-tested targets are still dispatched to a focused renderable.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/anomalyco/opentui/pull/663 **Author:** [@remorses](https://github.com/remorses) **Created:** 2/10/2026 **Status:** ✅ Merged **Merged:** 2/11/2026 **Merged by:** [@kommander](https://github.com/kommander) **Base:** `main` ← **Head:** `fix-scroll-fallback-focused-target` --- ### 📝 Commits (3) - [`d73bd3b`](https://github.com/anomalyco/opentui/commit/d73bd3b366b0b58efbd6f77d30fca6f725bd0b33) fix(renderer): fallback scroll events to focused renderable - [`1166999`](https://github.com/anomalyco/opentui/commit/1166999dae5b24bc5e74ee780ed38fdd91aaad3e) fix: add .focused check to scroll fallback target and clarify test name - [`7ea7a2c`](https://github.com/anomalyco/opentui/commit/7ea7a2c338b346f62046fbb240b977a6f5aa8e01) Merge branch 'main' into fix-scroll-fallback-focused-target ### 📊 Changes **2 files changed** (+43 additions, -5 deletions) <details> <summary>View changed files</summary> 📝 `packages/core/src/renderer.ts` (+11 -4) 📝 `packages/core/src/tests/renderer.mouse.test.ts` (+32 -1) </details> ### 📄 Description ### Why I hit this while testing `critique`: mouse-wheel scrolling was not working reliably in the main diff scrollbox unless the pointer happened to be over a hit-tested renderable cell. That made the scrollbox feel broken in normal usage. ### Problem For wheel events, renderer mouse handling currently consumes scroll input even when hit-testing returns no renderable target. In that case, no `onMouseScroll` handler runs, so focused scroll containers can appear unresponsive. ### Fix I kept existing hit-test dispatch and added a fallback target: - if hit-test finds a renderable, dispatch there (existing behavior) - if hit-test misses, dispatch to the currently focused renderable (new behavior) This preserves current semantics while making wheel input reach the active scroll container when the pointer is over non-hit-tested cells. ### Validation I added a regression test in `packages/core/src/tests/renderer.mouse.test.ts` that verifies scroll events outside hit-tested targets are still dispatched to a focused renderable. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>