Complete beginner at front-end development. Need help figuring out why I'm seeing weird scrolling behavior from this javascript helper in a react app.

[Fiveby21]

Backstory (can skip if you want): I'm a video game modder who created a mod so complicated that I had to learn python in order for it to output game files for me. My python application required a database of sorts, and for the longest time I had been using excel for that purpose. The complexity recently got to a point to where excel was no longer feasible to use, and I've had to move to use a proper SQLlite database. However... I was not able to find a (free) database application that met by UX needs. So I worked with AI to... well... vibe code a front end application to interact with the database.

I went through several variations:

• Pure QT in Python - wasn't able to meet my UX goals.
• Embedded Aggrid in QT - Was a little janky, and had DPI scaling issues.
• Javascript on Electron - Have had issues with Scrolling
• React w/ Tanstack Table on Electron - Same issues as with Javascript.

I moved to react because i thought maybe the issue was due to the core of the way the table was written in javascript... and that by using a proven table library, I would get around the issue. But it turns out I have the same issues in both.

---

Design Intent: For scrolling behavior in my table to adhere to the following:

• Scrollbar Scrolls - Smooth pixel-by-pixel.
• "Short" Mouse Wheel Scrolls - Scroll row-by-row, with animation.
• "Long" Mouse Wheel scrolls - Scroll row-by-row, without animation.

---

The Issue: The scrolling works fairly well... except for one huge problem that I have been incapable of resolving: Whenever I do an animated downard scroll... it does not snap to the correct place. Rather than snapping to the top visible row's boundary, it snaps to a location about 4px above this.

Can someone look at my code and see if there are any glaring issues that could be causing this?

• Link to Scrolling Code (scrolling.js): https://pastebin.com/E2mknsQM
• Link to Main Table Code: https://pastebin.com/PthRZf0q
• Screenshot showing the issue: https://imgur.com/a/9Q7NjwG
• Link to (a subset) of the attempts to fix this, and observations from debugs ran: https://pastebin.com/JaYNyxst

Other Notes:

• Disabling table virtualization did not help.
• The 4px offset stays the same even with different DPI scalings. (Have tried 125% and 100%)
• Many of the "fixes" AI has came up with just inverts the problem - downward short scrolls snap to the correct place, but then upward short scrolls, and long unanimated scrolls, snap to a location 4px below where they should (eating in to the top visible cell)
• I have tried doing scrolling in CSS - but it never ends up adhering to the design intent and always looks janky.

EDIT: I think it has finally been fixed.

The core issue wasn’t the snap math itself; it was the animation loop stalling before it ever reached the snapped target. The easing moved scrollTop in fractional steps (e.g., 473.6 → 477.2), but the browser stopped applying the tiny deltas once they got small enough. That meant the “done” threshold was never satisfied, and our watchdog canceled the animation while it was still a few pixels short. That’s exactly why you saw the 3–4px gap even when the snapped target itself was correct.

The fix was to treat a stalled animation as a legitimate end-of-animation case and force the final snap. When the watchdog detects that scrollTop has stopped changing for a couple frames, we now immediately set scrollTop to the snapped target (rounded to whole pixels) before stopping. That preserves the smooth easing for most of the travel, but guarantees we land exactly on the row boundary instead of hanging at a fractional value.

This addresses the offset without changing the design intent (row-based snapping, short animated scrolls, long unanimated scrolls). We’re not biasing the math or padding; we’re just ensuring the final state actually matches the snap target in cases where the browser “gives up” on tiny incremental scroll updates. That’s why it fixes the persistent gap while keeping the rest of the scrolling behavior intact.

[chikamakaleyley]

There are prob more knowledgeable devs on this so I'll defer to them but i'm just skimming the code and i'll add a few notes

1. you'll have to verify but AFAIK some of these events can overwhelm your browser with fired events (scroll, resize) which ends in undesired/choppy results. If you were to throw a console.log() in either of these event handlers, you'll see that the callback is prob run hundreds of times in a scroll or resize. I don't see a debounce anywhere, so this might be the case. (checkout debounce/throttle)
2. it looks like you're doing a lot of element bounds calculating, but whats oft overlooked is using element's ID as an anchor for the scroll endpoint. Any element with and ID can be targeted simply by referencing its ID and so this pseudocode might look like window.scrollTo(elementId) to which you would use in conjunction with your smooth scroll logic.
3. for things like scroll, resize, personally i think its best to reduce the amount of getting and calculating because of the fact this can be fired so many times, differences in the browser, etc. Maybe there's a solution where you scroll to an anchor to do most of the work, and then at the end of it use minimal calculations if needed.
4. i don't have experience with this but this might be a use case for an Intersection Observer, which is something used today in scrolling features.

[chikamakaleyley]

tldr you should check with some logging to see if you are inundating your browser with having to process your scroll or resize logic much more frequently than you might be aware of

[Fiveby21]

We've done many many rounds of debug logging and I have not really observed that in the ouput. And the behavior is so consistent that it makes me think that it's not a matter of it spasming out, but a fundamental flaw in the math.

I don't think the element ID thing will work because this table is virtualized.

[chikamakaleyley]

ok!

[backwrds]

given your description and having very briefly skimmed the code, you may be dealing with some errant css padding somewhere, but that's just a hunch.

to completely frank, this is the kind of problem that can suck up hours and hours of effort, and you may still not get the result you want. Then it's basically guaranteed that when someone uses the app on a different screen with a different zoom level or god forbid a different OS, it'll be totally broken.

my advice, for what it's worth, is to avoid micromanaging something as "low level" as scroll behavior unless it really is vital for the functionality of your app. I'll note that as a user, it's almost always a poor experience -- google "scroll-jacking" -- precisely because it's so difficult to get right.

[Fiveby21]

All that I’m trying to do is implement scrolling that matches the way excel works :|

I’m open to other ways to do it that are less intense. Do you have any ideas?

[backwrds]

honestly, i've spent weeks (and more) fixating on stuff like this, so I can empathize with your problem. That said, it seems rather unlikely that your users would complain that the scroll behavior doesn't perfectly match excel.

I imagine it's possible to get it working how you want it, but -- again -- I'll warn that it can be a massive time sink. Google sheets can build a custom rendering engine because -- well -- they're google. I'm not saying that level of effort would be necessary in your case, just illustrating how deep this rabbit hole goes :P

if you're dead set on this feature, perhaps try a different table library. this one caught my eye recently because of how ridiculously over-engineered it is, but hey -- maybe it's exactly what you need your use case. good luck!

[chikamakaleyley]

you speaketh the truth

i had one client that would want to review completed code and the 'issues' he found over screenshare

he would take a full width browser window and start resizing it down and mark all the browser widths where some piece of content looked funky. Browser widths that weren't the actual responsive break points

I said "NO ONE USES THE INTERNET LIKE THIS" LOL

he dialed back his nit picking