Vertical continuous scroll in page view can settle below rendered system boundary

[AvaTheArchitect]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

In vertical/page mode with native ScrollMode.Continuous, alphaTab appears to scroll toward the active beat/staff coordinate rather than the rendered system/SVG row boundary. On rows with taller visual content — palm mute lanes, effects text, bends, ties, pick slides, lyrics/annotations, or extended visual bounds — the scroll can settle too low and leave part of the previous system visible.

The behavior was reproduced in:

• a native/default alphaTab Vite-style setup
• our Maestro implementation before changing scroll ownership

We traced the delayed scroll writer and confirmed this stack:

VerticalContinuousScrollHandler.doScroll:
→ BrowserUiFacade.scrollToY
→ BrowserUiFacade._internalScrollToY
→ scrollTo({ top: ..., behavior: "smooth" })

In our app, a custom row-boundary snap would land correctly at rAF1/rAF2:

target: 874
scrollTopNow: 874
prevBottomNow: 8
chosenTopNow: 8
prevDanglingNow: 0

But around 50ms–150ms later, alphaTab’s native VerticalContinuousScrollHandler issued a smooth scroll and pulled the viewport back down:

scrollTopNow: 835
driftFromTarget: -39
prevDanglingNow: 39

That later native smooth scroll exposed part of the previous system again.

As a workaround, we set portrait/page mode to ScrollMode.Off and let our own system-row snap own vertical scrolling. That stopped VerticalContinuousScrollHandler from issuing the later smooth scroll and eliminated the dangling previous-system issue.

This suggests page-view continuous scrolling may need to account for the rendered system/SVG row boundary, or at least the visual bottom of the previous system, rather than only following the active beat/staff coordinate.

Here are a few images from different alphaTab Platforms:

This is on the LouisLam Vite and v.1.8.1 on Chrome Desktop

Same Vite system




Same issues as vite but now on the Next.js and webpack running v.1.8.1 and also on Chrome Desktop (Before Workaround Fix Applied)




Here is the element inspector revealing the issues (Before Fix)




Same thing for the row beneath the dangling notation legs (Before Fix)




Guitar Pro 7 showing the clean snap to edge to edge on SVG




GP7 again




Same GP7 last one from this demo




Here are the After Fix Images




(After Fix)




After Fix with Element Inspector




Same thing next row down

Expected Behavior

In vertical/page layout with ScrollMode.Continuous, alphaTab should scroll to a position that fully clears the previous rendered system/SVG row when advancing to the next system.

The current native scroll behavior appears to use the active beat/staff coordinate as the scroll target. In page/vertical layout, that can leave the previous rendered SVG row partially visible after the native smooth scroll settles.

The scroll target should also account for the previous rendered system’s visual bottom edge — effectively the SVG row boundary — so the previous system is fully cleared when advancing to the next system.

Expected result:

• The next system should land cleanly in the viewport.
• The previous rendered SVG row/system should not remain partially visible at the top.
• Notation fragments such as stems, staff lines, palm-mute lanes, bends, lyrics, or other above/below-staff elements from the previous system should not be left dangling after the native smooth scroll settles.
• This should work consistently even when the active beat is on lower strings or when the previous system has taller visual bounds.

Steps To Reproduce

Play any GP file and possibly XML file in the alphaTab players and see some rows land on the A string or Low E string instead of the SVG edge.

Link to jsFiddle, CodePen, Project

No response

Version and Environment

alphaTab and webpack v1.8.1
Vite v.1.8.1
Chrome Browser testing on Desktop

Platform

Web

Anything else?

I’m not sure what the best internal fix would be, but the workaround suggests the native page-view scroll target may need to become system/SVG-boundary-aware rather than relying only on the active beat/staff coordinate. As we would create a PR but the auto-scroll if the missing element for us here.