[Webkit-unassigned] [Bug 212019] New: Scroll position of page keeps changing as I try to read it

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=212019

            Bug ID: 212019
           Summary: Scroll position of page keeps changing as I try to
                    read it
           Product: WebKit
           Version: Safari 12
          Hardware: iPhone / iPad
                OS: iOS 13
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Layout and Rendering
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: nickshanks at nickshanks.com
                CC: bfulgham at webkit.org, simon.fraser at apple.com,
                    zalan at apple.com

Note: I don't know what version of Safari is running on my phone, as it's not shown under Settings.app > General, nor Settings.app > Safari, nor in the Mobile Safari app AFAICT. The phone has iOS 13.3.1 installed.


Abstract:
I clicked a link in the Twitter iOS app to https://wholemars.net/2020/05/17/frederic-response/ and had a terrible user experience, fighting with the site and/or WebView, which kept changing my scroll position. In the end I gave up with iOS and switched to my laptop to read the article. i propose a solution which will improve the user experience.


Long version with most expletives removed:
The link opened in the app's WebKit view, and I began reading. Judging by the length of the article, it would take about 30 minutes to read it all in good conditions. About 20 seconds in, the view switche(d/s) to Reader Mode, which was a little annoying but not enough to make me file a bug, though it would be nice if it started rendering in Reader Mode straight off the bat. (I assume by the time of first paint, you already have enough consecutive P tags to realise this is a text-dominant web page.)

During reading of the article, the scroll position jumps around so often and to such a degree that it makes it near impossible to read to the end. The effect seemed greater the further down the document you are, both in the frequency and magnitude of the scroll position changes. At about 80% of the way down the document, it was often taking me longer to re-find where I had gotten to, than the scroll position change interval, thus I was unable to continue reading the page.

I tried turning off Reader Mode, this didn't help. I tried reloading the page within the WebView (returning to the linking tweet and re-clicking), this didn't help. I tried opening the URL in iOS Safari. This also did not resolve the jumping around.
In the end I switched to my Mac and loaded the page with Javascript disabled. This resolved the poor experience and I was able to complete reading the page. Trying it now (+24h later) on desktop with JS on, I don't see the jumping around. Thus I don't know whether to blame the website or iOS WebKit, but in either case, the issue can be solved with some smarter generic behaviour from WebKit.

I don't know if the document length changes were due to images loading very late, javascript on the page doing weird shit, or something else, but it would be much better if, when any document DOM changes in height and the scroll position ≠ zero, the deepest DOM element in normal flow in the viewport remains the same number of pixels from the top of the viewport as it was before the height changed. During an iOS scroll, use the element under the user's finger. That element should track the user's finger and any changes earlier in the DOM during the scroll (e.g. images which load and cause re-layout) should push the top of the page further away, or bring it closer to the viewport (for height increases, decreases respectively), just as DOM additions after the current viewport push the bottom of the document further away from the viewport.
In short, do whatever you can to keep what's on the screen still on the screen despite adversarial DOM changes.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20200518/61178830/attachment.htm>