Temporarily hold timeline if mouse moved recently (fixes #8630)

[lmorchard]

• On recent mouse movement, hold timeline position so statuses remain in
  place for interactions in progress.

• If the timeline had been scrolled to the top before mouse movement,
  restore scroll on mouse idle.

[Gargron]

You should know I have implemented and then reverted a similar patch. The mouse moves all the time. Having the timeline constantly stuck in the past is very frustrating. Ref: #4859, #4865 (looks like you already know about that as you commented in that one)

[Gargron]

I can see one difference is that the old patch was based on the hover state, while yours is based on move timing. It could be better but I don't know by how much.

[lmorchard]

You should know I have implemented and then reverted a similar patch.

Yeah, I figured I'd give it one more shot, because mis-clicking on the wrong status really bothers me. If this attempt gets rejected, I'll understand. 😅

For what it's worth, I used a timer because the _recentlyMoved logic wouldn't be checked until the next mouse move or other column state update (e.g. new statuses).

I think a timer makes this more responsive - because one of the things I've got it doing is scrolling back to the top of the column on mouse idle, so that it doesn't actually stay stuck in the past.

[lmorchard]

Pushed a small tweak to better clear the timer, since I realized the property never returned to null after a clearTimeout

[Gargron]

I think a timer makes this more responsive - because one of the things I've got it doing is scrolling back to the top of the column on mouse idle, so that it doesn't actually stay stuck in the past.

I have to ask - what if I intentionally scroll down to visually mark my position on something. This would pull me back to top?

Consider an alternative to this is disabling updates on mouseDown, since the click event is fired on mouseUp, the most annoying things are when you click on something and then it moves from under your mouse when you release, right?

[lmorchard]

I have to ask - what if I intentionally scroll down to visually mark my position on something. This would pull me back to top?

No, if you're not at scrollTop === 0 when a mouse move starts, scroll to top on idle doesn't happen. So, if you're scrolled down at the start of a mouse move, this code does basically nothing.

Consider an alternative to this is disabling updates on mouseDown, since the click event is fired on mouseUp, the most annoying things are when you click on something and then it moves from under your mouse when you release, right?

I don't think pause-on-mouseDown would help. For me, the issue feels most often like the timeline has moved in the span of approaching, landing on, and then clicking on a UI element. The mouseDown / mouseUp span is the shortest part of all that.

[Gargron]

Okay, so there's kind of only one way to find out. I will merge this, it will get some use from people running master, and then we'll know if it's a good change or if the behaviour will be disturbing. Fingers crossed but if it'll turn out worse I'll revert it, just a heads up 🙏

[lmorchard]

Fingers crossed but if it'll turn out worse I'll revert it, just a heads up 🙏

Yay, thanks for the consideration! No worries from me if it gets reverted. Figured I'd give it one more try

[Gargron]

@lmorchard Could you please investigate #9217 as I am now getting complaints from people on servers running master. It seems that this patch interferes with manual scrolling. If it's the result of a minor bug, it would be great to find it, otherwise I am preparing to revert this.

[lmorchard]

Sure, I will take a look in a few hours. I think I see what's going on.

Edit: I see there's already a PR to revert - should I investigate? Or are you already on path to revert?

[Gargron]

As I said I am prepared to revert, but I can wait until you investigate.