diff --git a/plugin-designs/research-dashboard/src/components/dashboards/DashboardDataTable.vue b/plugin-designs/research-dashboard/src/components/dashboards/DashboardDataTable.vue index beff6f8f1..cadfc02c8 100644 --- a/plugin-designs/research-dashboard/src/components/dashboards/DashboardDataTable.vue +++ b/plugin-designs/research-dashboard/src/components/dashboards/DashboardDataTable.vue @@ -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; }