1877069 - New Tab top-overlay obscures content that just became visible via e.g. a "page-down" action

Status: NEW

(Firefox :: New Tab Page, defect)

Description

[Daniel Holbert [:dholbert]]

STR:

1. Make your browser-window tall enough so that the new-tab page shows a partially-transparent "overlay-header" at the top when you scroll down (keeping the searchbar/cog-icon in view). (e.g. by maximizing Firefox, on my 1920x1080 display at least)
2. Open a new tab. Pay careful attention to what the last line of content is that you can read in one of the new-tab tiles. (For me, I can barely read the first line of the tile titles)
3. Hit your PageDn/Page-Down key on your keyboard.

EXPECTED RESULTS:
The content that was just-offscreen in step 2 should now be clearly visible near the top of your scrollport.

ACTUAL RESULTS:
The content that was just-offscreen in step 2 is at very top of the scrollport, and it's unreadable because it's covered up by the partly-transparent header-bar.

Comment 1

[Daniel Holbert [:dholbert]]

Note: when the transparent-header is already visible, we seem to match my expectations and reduce the scroll-distance that PageDn/PageUp will scroll.

But in that first PageDn scroll operation where the transparent-header becomes visible as a result of the fact that we're scrolling, we seem to scroll too far.

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: screencast showing the bug (scrolling too far; top edge of scrolled-in content gets covered up by overlay)

Comment 3

[Daniel Holbert [:dholbert]]

In the attached screencast, note that the center tile's first line How to make southern butter is all that's visible.

When I hit PageDn, I expect to be able to read the rest of that tile, but in fact the tile's text ends up ~fully obscured by the searchbar in the transparent-header overlay that appeared during the scroll operation.

Comment 4

[Daniel Holbert [:dholbert]]

Attachment: screencast of good/expected results when the overlay is already there

In contrast, here's us doing the correct/expected thing after you scroll down a bit such that the overlay shows up. Focusing on the center tile at the bottom of the screen (whose first line is How to Stretch Everything That): after the PageDn operation completes, that first line of text and the rest of the tile are all clearly visible and not-covered-up by the transparent-header overlay.

Comment 5

[Daniel Holbert [:dholbert]]

I suspect that maybe the reduced-scroll-distance thing shown in comment 4 here might just be something we automatically do when there's a fixed-position overlay at the top of the screen. (hiro might recall if that's a real thing vs. if I'm making that up; but I'm pretty sure that's a real thing.)

If that's the case here, then: to get expected-results here, we might just need to ensure that there's already a properly-sized-but-invisible/non-functional fixed-position overlay at the top of the screen, if we intend to move the searchbar to be a fixed-position thing as soon as the user starts scrolling. That invisible fixed-position overlay might be sufficient to reduce the scroll distance for the first scroll operation as-expected here.

Comment 6

[Hiroyuki Ikezoe (:hiro)]

Yeah, you are correct. Once after we fixed bug 1873067, then we can just specify scroll-padding-top there to avoid this issue.

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:amy, could you have a look please?

For more information, please visit BugBot documentation.