-
Bug
-
Resolution: Fixed
-
Low
-
None
-
4.1.3, 4.1.4
-
None
-
Severity 2 - Major
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:
- 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.
- View the list of uncommitted changes in Tree view and observe the stunted scrolling behavior.
- Switch to flat view and observe normal scrolling behavior.
- 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.
- is duplicated by
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
[SRCTREE-7775] File List Doesn't Scroll Properly in Tree View
Confirmed still an issue with Tree view on 4.2.0 with MacOS 12.6 and Logitech MX Master mouse. Not an issue with touchpad or Apple magic mouse.
I just applied the latest update. As others have noted, the behavior using the trackpad has returned to the expected behavior but the physical scroll wheel on a mouse is still exhibiting the buggy behavior. For the record, I'm using a logitech M557 without any third party controllers or utilities – just Apple's native mouse controls. But the model of mouse does not seem to be a factor – I also happen to have a very old (like maybe 15 years) wired logitech wheel mouse here so I plugged it in and tried it – same behavior using its wheel.
Using
- the latest SourceTree upgrade 4.2.0 (246)
- MacOS 12.5.1
- Logitech wired mouse with clickable scroll wheel (as above .. logitech site says this is a M500S ADVANCED CORDED MOUSE from the serial number and part number, but I have my doubts)
still get problems with the scroll wheel
- Using scrollbar everything is fine
- Using the mouse wheel with the precision click-to-click (not the free spinning mode) it scrolls very slowly (see https://www.logitech.com/assets/50122/corded-mouse-m500-qsg.pdf)
- Using the mouse wheel with the free spinning move, no effect at all, no scrolling
So my observations concur with AlexFooCL above. I saw someone did some lower level event debugging, looks like they were on to the answer... Get a Logitech wired mouse with scroll wheel and see what event stream assumptions you make are wrong!
good luck
Arati Mohanty
- Click and Dragging the scrollbar using Macbook Track Pad/Mouse works normal.
- Swiping using the Macbook Track Pad works normal.
- Scrolling using a physical mouse scroll wheel (Using a generic Logitech mouse) does not work normally - the list moves by only 'one line' for many wheel scrolls
I've since moved on to Fork months ago just thought I'd give some feedback since the machine I'm using have the latest Sourcetree 4.2.6(246) installed. Good luck guys!
54962a23a08b c7d62163757c Thank you for your valuable feedback. Our team will start analysing the issue deeper and update on the fix.
Still seeing the issue. 
Guys, I recommend you purchase a Logitech Monster Mouse M2 or M3 from the looks of it and try to reproduce this. I don't know your internal process but why does this JIRA still need triage? Looks to me like a pretty impactful problem.
We're also seeing this issue with the recent 4.2 update and the Logitech MX Master 3 mouse wheel.
It's incredibly, incredibly frustrating (though slightly less frustrating than encountering this issue page and seeing how long this "low priority / needs triage" issue has been affecting people).
The basic usability of Sourcetree on Mac has been so disappointing lately.
Looking forward to an update soon.
e8a4f87cc5c4 , john.francis ,54962a23a08b
Thanks for your feedback and analysis. We created internal spike task to analyse this strange scrolling behaviour of tree view using mouse with "physical scroll wheel".
Most probably, there is some small difference in "scroll api" calls between mouse with "scroll wheel" and mouse with "swipe sensor" (like Magic Mouse) and we just not handling scroll notifications properly when trying to preserve scroll position of tree view after it refreshes. Will see.
We will analyse it and after this we will work on fix to provide it in one of upcoming releases (it will definitely be after 4.2.0 release, because it will be available very soon). I'll let you know, if we will need to collect additional details about this issue.
Just wanted to confirm that it works fine for me now. Thank You.