A user recently pointed out to me that there is a bug in WebView’s handling of nested scrolling which causes the long-press menu to appear when the user’s finger is on a link, the app bar is being scrolled on or off the screen, and the scroll moves at a slow pace. This is caused because, when the app bar is scrolling, the position of the touch above the link is not changing, which causes the system to calculate it as a long-press. This can be seen in the video below, where the link maintains a highlighted blue background while scrolling because the touch maintains position over the link as the app bar is scrolled.
Most browsers hide and show the app bar based on changes in the scroll position of the WebView. However, because JavaScript can modify the reported value of the WebView scroll position, this can lead to significant spoofing bugs. Privacy Browser uses a nested scroll design, where the scroll is first passed to the app bar, which then passes it down to the WebView. Hence, Privacy Browser is not susceptible to JavaScript shenanigans, but it does result in this undesirable behavior.
Users can work around this problem by doing one of the following.
- Disable app bar scrolling in the settings.
- Scroll faster than the speed that triggers this bug.
- Not place their finger on a link when scrolling.
None of these is an ideal solution. However, it is interesting to me that this bug has existed since the release of Privacy Browser 3.0 in April 2019, and I have never noticed it myself nor has any user brought it to my attention until now. My guess is that is because most people naturally scroll faster than the speed required to trigger the bug.
It might be possible to fix this bug with Privacy WebView in the 4.x series. In any case, the real fix should be Google correctly supporting nested scrolling in WebView, which, for some unknown reason, they appear unwilling to do.