vertical scrolling by PageUp or PageDown may skip lines
Categories
(Core :: Layout: Scrolling and Overflow, defect)
Tracking
()
People
(Reporter: Nick_Levinson, Unassigned)
References
Details
Attachments
(3 files)
On some pages, vertical scrolling with Page Up or Page Down skips lines of text. For example, https://css-tricks.com/a-complete-guide-to-links-and-buttons/ (as accessed 8-1-20) skips about 3-4 lines or equivalent vertical space. This seems unaffected by specific content. I do not know if framing is relevant. This is important when we scroll to eyeball to find something and skipping lines means that what we want to find flies by without our seeing it. The Find function may not be a helpful substitute if we know only approximately what we want.
Chromium also skips, although not as much. It skips ab out 2 lines or equivalent. The Chromium version is 84.0.4147.89 (Developer Build) Fedora Project (64-bit).
Here's another URL, cited because it may have a different cause, what appears to be a floating element: https://www.npr.org/transcripts/898274915 (as accessed 8-2-20). The floating element may exist or not depending on your locality; there should be something mentioning a local radio station, and probably displays mainly if viewed from a U.S. IP address near a local radio station that carries NPR radio programming. The skipping of lines is only behind the floating element, so part of each skipped line is still visible to the left of the floating element.
Expected behavior is that there'd be a slight overlap, perhaps that the bottom line visible in the viewport would, on a Page Down press, would become the top line in the viewport, and vice versa for Page Up. No overlap is acceptable as long as there's no skipping, either.
Regarding this css-tricks.com page, I contacted the website's management and was told that they can't control that.
The version is 79.0 (64-bit) but the problem is not new. I use mainly a Dell Latitude E6400 laptop running Fedora 32 Linux kept evergreen.
Possibly of interest: bug 684184 and bug 205845.
![]() |
||
Comment 1•5 years ago
|
||
I can reproduce the issue on Nightly81.0a1Windows10.
Comment 2•5 years ago
|
||
Is there a reduced testcase here? I landed a fix for sticky items in bug 1308286 last year.
![]() |
||
Comment 3•5 years ago
|
||
Comment 4•5 years ago
|
||
Comment 5•5 years ago
|
||
Comment 6•5 years ago
|
||
Comparing testcase 2 against my just-posted modified version, you can see that we scroll by exactly the same amount in both. It's just that in testcase 2, there's a sticky header that remains behind and covers up the top of the screen (the top of the new content that we just scrolled into view).
tnikkel, maybe you could you take a look? This seems like a case that bug 1308286 was intended to address, but didn't for some reason.
(Also: FWIW, I loaded the testcase with Nightly 2019-10-11 using mozregression -- that's the Nightly from a day or two after bug 1308286's fix landed -- and I'm seeing this issue using that build as well. So this is indeed a case that wasn't addressed by the fix there -- it's not a regression.)
Updated•1 year ago
|
Description
•