File List Doesn't Scroll Properly in Tree View

When in Tree View, the file list scroll position does not move in proportion to the number of files displayed. It is difficult to navigate. At times it feels like the scroll position isn't moving, as if it thinks it's at the bottom of the list, or as if the mouse tracking speed is a small fraction of its normal speed. The effect seems to increase with the number of files in the list and can be nearly impossible to use with a lot of files. If there are only a few files outside the visible area, the scroll position moves nearly as expected but if there are many files out of view the scroll position hardly moves at all.

This happens in the file list that displays uncommitted changes (staged and unstaged) both in the File Status and History workspaces, but not in the file list in previous commits in History. The behavior happens in Tree View regardless of the sort and regardless of the style of the staging view (split or fluid). Turning off Tree View and using either of the flat list options restores the expected scrolling behavior.

The problem occurs when using the mouse wheel, using touch gestures on the trackpad, and when click-dragging the scrollbar itself. When using the scroll wheel or the trackpad gestures, it feels as if the tracking speed is intolerably slow – it does move, but not as expected. When dragging the scrollbar itself, the scrollbar will move fluidly with the mouse cursor and analogous to my hand movement, but the visible area does not move in proportion to the amount the scrollbar is moving, and when released, the position of the scrollbar snaps back to its original position or near to it.

I'm not sure when the problem was introduced. I would estimate within the past several weeks. It may have coincided with my upgrade to macOS Monterey, or it may have coincided with a recent update to Sourcetree itself; I'm not sure. I did not notice which version of Sourcetree I was using when it started, but I did apply an update today before reporting the problem, which brought it to the current version and the problem persists. I have auto updates enabled, so my guess is that I was one version back before I applied the current update.

Steps to reproduce:

1. Produce changes to files in multiple subdirectories of a repository, such that the number of files and directories containing changes exceeds the visible area of the file view with Tree View enabled.
2. View the list of uncommitted changes in Tree view and observe the stunted scrolling behavior.
3. Switch to flat view and observe normal scrolling behavior.
4. Produce changes to additional files to increase the size of the list and observe a worsening of the effect.

For reference on the number of files: I have one repo with 17 file changes in 5 different directories from top-level to 3 directories deep. The behavior is present, but I am able to navigate this list with only some difficulty. I have another repo with 874 changes up to 7 directory levels deep. The scroll won't even move. The second case is an extreme, but both of these cases scroll normally when switched to flat mode, and this was not a problem on these same repos in the past, even with large changesets.