Scroll position adjusts even if thumb not moved

[inexorabletash]

To Reproduce Steps to reproduce the behavior:

1. Start DeskTop
2. Navigate to Sample.Media
3. Preview Lorem.Ipsum
4. Scroll about 3/4 down the file
5. Click in the vertical scrollbar thumb, and release without moving the thumb

Most of the time the thumb will shift by a few pixels and the content will scroll.

Expected behavior Scroll thumb stays where released, content doesn't scroll.

MGTK's TrackThumb logic appears to not be "stable"; that is, after moving the thumb (which may result in an adjustment as the pixel position is mapped to a scroll fraction, then back), a subsequent non-move of the thumb results in a different position.

To fix will probably require deconstructing the current math and figuring out where the loss is happening.

[buserror]

Could it be related to the code that seems to reduce the resolution of the mouse? For example, in a window, if you click+drag a selection, the selection doesn't follow the mouse exactly, it's quantified and moves in 'steps'...

[inexorabletash]

I don't think so. You can visually see the thumb rect being unchanged from the previous position, and it's the thumb rect that's the input to the calculation.

[inexorabletash]

After staring at the code for a while, the description is incomplete, and it may not be localized to MGTK. Here's the whole process for Show.Text.File:

• Scroll position is set somehow.
  • In the client code first_visible_line is set (range is 0 to max_visible_line)
  • In MGTK, the winfo'svthumbpos is set (range is 0 to kVScrollMax)
• OnVScrollThumbClickThumb invoked
  • MGTK's TrackThumb is called, and returns a new thumbpos (range is 0 to kVScrollMax)
  • Note that the winfo's vthumbpos is NOT CHANGED
  • However, it's possible that the rect didn't actually move yet the thumbmoved flag is set (!)
  • first_visible_line = max_visible_line * thumbpos / kVScrollMax
  • thumbpos = kVScrollMax * first_visible_line / max_visible_line
  • MGTK's UpdateThumb is called with new thumbpos

In an example (with Lorem.Ipsum sample), I can see TrackThumb returning $B8 and then UpdateThumb called with $B3, so it's the client (Show Text File) at least partly to blame - those numbers should match! But when the thumb is next clicked w/o no movement, TrackThumb returns $B2, where I'd expect $B3 again.

[inexorabletash]

... and unsurprisingly, the thumbpos changing is due to integer math, e.g.

• first_visible_line = max_visible_line * thumbpos / kVScrollMax
  • first_visible_line = $25 * $B8 / $FF = $1D
• thumbpos = kVScrollMax * first_visible_line / max_visible_line
  • thumbpos = $FF * $1D / $25 = $B3

This can be avoided by just using the thumbpos returned from TrackThumb, with no changes to MGTK. However, this is still not ideal, because (1) it requires all clients to make similar logic changes and (2) the thumbpos change still happens due to MGTK's calculations and (3) if the flag is set it can still trigger an unnecessary redraw.

So a fix to the logic in MGTK's TrackThumbImpl is still desirable.