doxa-life/doxa-maps
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Take overscroll-behavior back off the table, and record what the wheel actually hits

Browse source 
The previous commit set overscroll-behavior:contain on .rd-grid to stop it
swallowing the wheel. That is backwards. contain prevents a scroll which bottoms
out in an element from chaining to its parent, and chaining to the parent is the
behaviour that would let the page keep moving once the table is exhausted.
Measured before and after: the symptom did not move at all, because a table with
54834px of content never bottoms out in the first place.

It is left at the default.

The diagnosis that produced it was reached by geometry, and geometry was the
wrong instrument. getBoundingClientRect placed this element at y=673-880, well
below the y=420 gesture, which appeared to exonerate it; a deep shadow walk had
earlier reported its scrollTop moving, which appeared to convict it. Both are
readings of state at some moment, not of what the browser dispatched. A
capture-phase wheel listener reading event.composedPath() settles it: at y=420
the path is rd-td, rd-row, rd-grid, rd-table-wrap. Use the event path when
geometry and behaviour disagree.

The underlying bug is still open and is a layout mismatch rather than a CSS
property: the research dashboard is a fixed-viewport grid that gives its table
34% of the band and legitimately owns the wheel inside it, hosted in a composite
that expects the page to scroll past it. That needs a design decision, not a
fourth attempt at a one-line fix.
This commit is contained in:
doxa-maps-88655c70 2026-09-23 00:40:33 +00:00
parent 285ba39c31
commit b40fd5b48d
1 changed files with 12 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

13
plugin-designs/research-dashboard/src/components/dashboards/DashboardDataTable.vue
View file

@ -488,7 +488,18 @@ useShadowStyles(`
culprit, and syncScrollZoomToHost genuinely did sample a layout-dependent condition on fixed
timeouts, so fixing that felt like fixing this. It was a real race and a real fix — just not
this bug. Verify the element under the cursor before blaming the one nearby. */
.rd-grid{ flex:1 1 auto; min-height:0; overflow:auto; position:relative; overscroll-behavior:contain;
/* ★ overscroll-behavior is deliberately LEFT AT ITS DEFAULT (auto). A previous fix for
BUG-CANNOT-SCROLL-DOWN-TO-THE-GRID set it to contain here, which is exactly backwards: contain
stops a scroll that bottoms out in this element from CHAINING to the parent, and chaining to the
parent is the behaviour that lets the page keep moving once the table is exhausted. Setting it
made the trap tighter, not looser. Measured: no change at all to the symptom, because the table
has 54834px of content and never bottoms out in the first place.
The wheel target here was verified by instrumenting the event rather than by geometry — a
capture-phase listener reporting event.composedPath() at the cursor. getBoundingClientRect had
reported this element well below the cursor and was misleading; the dispatched path
(rd-td -> rd-row -> rd-grid) is authoritative. Use the event path when the two disagree. */
.rd-grid{ flex:1 1 auto; min-height:0; overflow:auto; position:relative;
scrollbar-width:thin; scrollbar-color:var(--dx-scroll-thumb, #c4c8c0) transparent; }
.rd-grid::-webkit-scrollbar{ width:8px; height:8px; }
.rd-grid::-webkit-scrollbar-track{ background:transparent; }