Header on https://labo.nintendo.com/ does not stick to top of page.
Categories
(Core :: Layout, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox74 | --- | affected |
People
(Reporter: ktaeleman, Unassigned)
References
(Blocks 1 open bug, )
Details
Attachments
(1 obsolete file)
STR:
- Open https://labo.nintendo.com/
- fast scroll up and down
Expected:
- Navigation header sticks to top of page
Issue:
- Header lags behind causing it to jump around.
Tested in chrome where issue does not occur.
Comment 1•5 years ago
|
||
I can sometime see some flickers, but the sticky element doesn't jump at all. Is it a problem?
Comment 2•5 years ago
|
||
(In reply to Hiroyuki Ikezoe (:hiro) from comment #1)
I can sometime see some flickers, but the sticky element doesn't jump at all. Is it a problem?
Yes. Though they're not using position: sticky
(they probably should!), it's a top: <something>px
value kept with javascript.
Botond, opening the devtools (which IIRC disables paint skipping) makes this example just work... Do you know whether we should move this to the APZ component? I suspect you're way more familiar with this kinds of bugs...
Comment 3•5 years ago
|
||
Oh? That's not position sticky? I was blindly thinking it's position sticky. Thank you Emilio.
Comment 4•5 years ago
|
||
Issues that go away with paint skipping are usually invalidation bugs. If the page is changing top
via Javascript, that change should be propagated through the style system and ultimately cause a call to SchedulePaint()
. Then, even though scrolling doesn't cause paints to be scheduled (i.e. paint skipping), the style changes should.
Comment 5•5 years ago
|
||
Well, yeah, the problem is that the top
value gets set as a response to a scroll event, so after scrolling, thus the flicker.
Comment 6•5 years ago
|
||
That causes a small amount of flicker - the header is moved to the correct position on the very next paint after the top
value is changed. There's not much we can do about this part other than educate web developers to avoid scroll-linked effects. (The APZ frame delay mitigates this, but it's controversial and I expect the performance team will insist we remove it any day now.)
However, the fact that the header gets so far away from the top before being restored (and that opening devtools fixes this) suggests that there is an additional issue where several refresh driver ticks elapse where we could have repainted but didn't, because SchedulePaint()
was not called for some reason.
Comment 7•5 years ago
|
||
Pretty sure SchedulePaint() should be getting hit here: https://searchfox.org/mozilla-central/rev/ad6234148892bc29bf08d736604ac71925138040/layout/base/RestyleManager.cpp#714
Comment 8•5 years ago
|
||
Another possibility is that there is an invalidation bug later in the pipeline. For example, a paint is being scheduled, but it incorrectly reuses the previously built display list.
Comment 9•5 years ago
|
||
Setting apz.paint_skipping.enabled=false
does not resolve the issue, so whatever effect opening devtools has, it's not that.
Comment 10•5 years ago
|
||
Oh, opening devtools doesn't disable paint skipping, it disables APZ altogether.
So, please ignore what I said before about this being an invalidation problem (that was predicated on the assumption that the problem is solved by disabling paint skipping). It's just an instance of the usual problem with scroll-linked effects.
Comment 11•5 years ago
|
||
(In reply to Botond Ballo [:botond] [spotty responses until Feb 19] from comment #10)
Oh, opening devtools doesn't disable paint skipping, it disables APZ altogether.
(More specifically, it disables APZ for subframes, and on this page, the thing that's scrolling is a subframe (that happens to take up the entire viewport).)
Comment 12•5 years ago
|
||
Bug 1367770 tracks possible further efforts to mitigate the impact of scroll-linked effects on async scrolling behaviour.
The other thing we could do here is reach out the website authors and encourage them to use position: sticky
instead.
Comment 13•5 years ago
|
||
The component has been changed since the backlog priority was decided, so we're resetting it.
For more information, please visit auto_nag documentation.
Comment 14•5 years ago
|
||
The priority flag is not set for this bug.
:alaskanemily, could you have a look please?
For more information, please visit auto_nag documentation.
Comment 15•5 years ago
|
||
Re-setting the priority to P3, and clearing :alaskanemily's NI.
Updated•5 years ago
|
Comment 16•4 years ago
|
||
Updated•4 years ago
|
Comment 18•4 years ago
|
||
Comment on attachment 9156981 [details]
Bug 1612124 - Add close button and delay for milestone message. r=ewright
Revision D71068 was moved to bug 1612125. Setting attachment 9156981 [details] to obsolete.
Updated•3 years ago
|
Comment 19•3 years ago
|
||
Now the site in question hides the top navi bar when scrolling down with a CSS transition.
Description
•