In bug 1576770, we had a situation where scrollbar dragging did not work at all (for some scroll frames on a specific website) because APZ's notion of the mouse position in the coordinate space of the scroll frame was incorrect, and this led to APZ believing incorrectly that the mouse was far away from the scrollbar thumb, and therefore the scrollbar should be snapped to its position at the beginning of the drag.

It seems to me that it would have been possible for APZ to detect this inconsistency by performing the isMouseAwayFromThumb computation on the MOUSE_DOWN: if it returns true, we know something is inconsistent, since the MOUSE_DOWN hit the scrollbar thumb during the hit test, so it can't possibly be far away from it.

Having detected this inconsistency, APZ could have then disabled snapping for this drag block, and thereby avoided the severe symptoms of the bug, leaving the milder symptoms of bug 1719913 only (or, alternatively, it could have bailed out of APZ dragging altogether, and avoided even the milder symptoms, at the expense of a possibly less smooth main-thread drag).

We could consider deploying such a check now, with a view to mitigating future APZ scrolbar dragging bugs (based on past history, there are likely to be more in the future).

(In reply to Botond Ballo [:botond] from comment #0)

We could consider deploying such a check now, with a view to mitigating future APZ scrolbar dragging bugs (based on past history, there are likely to be more in the future).

Timothy, Hiro, I am curious what your thoughts are about whether such mitigations are a good idea.

I remember Kats' preference was that we not make such mitigations, because they can hide the underlying bugs and cause them to go unnoticed longer.

That is indeed a downside. On the other hand, bug 1576770 has been open and affecting TweetDeck users with WR enabled on Windows for almost 2 years, and having such a mitigation in place would have improved their experience.

I am curious what you think about this tradeoff.

As Botond and I chatted on Matrix, the mitigations sound reasonable to me. (I am assuming we will add at least one debug assertion (or warning) in the case of incorrect case).

I'm not sure enough people run debug builds where they are likely to encounter issues like this to be useful. I like the idea on matrix of having a pref and having the mitigations disabled on nightly.

Bug 1794590 is an example of a bug that the described change might have successfully mitigated.