1506121 - position:fixed not respected inside filter (causes stuttery scrolling on specific site)

Status: RESOLVED INVALID

(Core :: Layout: Scrolling and Overflow, defect)

Description

[Mayank Bansal]

Attachment: aboutsupport.txt

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:65.0) Gecko/20100101 Firefox/65.0

Steps to reproduce:

create new profile
WR/non-WR doesnt matter
go to https://web.archive.org/web/20150401205722/http://www.pokecommunity.com/showthread.php?t=161616

scroll


Actual results:

all elements stutter (move ertically up/down on scrolling)


Expected results:

not so

Comment 1

[Mayank Bansal]

Attachment: bandicam 2018-11-09 19-04-15-171.mp4

Comment 2

[Kartikaya Gupta (email:[e-mail])]

When I scroll I see similar stuttering, but it's not an APZ bug per se, it's the result of a toolbar appearing disappearing at the top of the page (behind the wayback machine header thingy). The toolbar appearing and disappearing shifts the content down and up. Somehow the toolbar's appearance is triggered by scrolling, I didn't look into it. This might be fixed by scroll anchoring, but other than that I don't think there's much we can do here.

Comment 3

[Mayank Bansal]

FWIW, this page works fine in chrome release

Comment 4

[Botond Ballo [:botond]]

(In reply to Mayank Bansal from comment #3)
> FWIW, this page works fine in chrome release

That's consistent with the scroll anchoring diagnosis, as Chrome implements scroll anchoring.

Comment 6

[Stefan [:StefanG_QA]]

This issue still reproduces on today's Nightly build with Scroll Anchoring enabled. (20190114104248)

Comment 7

[Ryan Hunt [:rhunt] (on leave until early May)]

I actually don't think this is going to be fixed by scroll anchoring, or that Chrome is better because of scroll anchoring.

The issue is indeed the navigation bar, but it's transitioning to and from 'position: fixed' in such a way that both Chrome and Firefox will suppress scroll anchor adjustments.

What's different is that on Firefox for some reason, it alternates constantly, while Chrome will only do it once and be done. I can see that when scrolling further down the page that the class switches between 'afix-top' and 'afix' on Firefox, but not in Chrome.

I haven't looked into it further than that unfortunately because I have too many other scroll anchoring things to get through first.

Comment 8

[Kartikaya Gupta (email:[e-mail])]

I spent some time investigating this one today. The switching between "affix" and "affix-top" happens in the bootstrap.min.js (v3.3.1) script, original source code can be seen here.

In summary, what happens is that the nav element on the page transitions from in-flow to position:fixed (this.affixed changes from "top" to false) when the scroll position exceeds 260. And then it's supposed to stay false as long as the nav element's top (as obtained by this code) stays above 260. When you scroll back up, that top value drops; eventually it drops below 260 and the reverse transition happens, with this.affixed going from false to "top".

In Chrome this works fine. In fact you can dismiss the wayback machine toolbar (there's a little close button on the right side) and then scrolling up and down the page you see the nav toolbar taking on this sticky behaviour correctly.

In Firefox, when the nav element goes to position:fixed it disappears from view entirely, and the top value comes back as 0. So this triggers the reverse transition right away, and as long as your scroll position is greater than 260 it will flipflop endlessly between the two states.

It seems to me that the underlying bug here is that even though the item is position:fixed with a top:0 CSS property, it's not actually fixed to the viewport, but instead ends up at y=0 of the document.

Comment 9

[Kartikaya Gupta (email:[e-mail])]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #8)

It seems to me that the underlying bug here is that even though the item is position:fixed with a top:0 CSS property, it's not actually fixed to the viewport, but instead ends up at y=0 of the document.

This underlying bug can be seen if you do the following:

• load the page
• dismiss the wayback machine toolbar
• use devtools to find the <nav class="page-navigation affix-top"> element and add position:fixed;top:0 to the CSS for it
• scroll down a few pixels

Observe how the nav element which should remain fixed to the viewport goes out of view as you scroll down.

With some more fiddling it looks like the root <html> element has a SVG filter on it which is responsible for this behaviour; disabling that CSS property makes the fixed-pos behaviour work as expected.

Comment 10

[Kartikaya Gupta (email:[e-mail])]

Attachment: Reduced testcase

Comment 11

[Emilio Cobos Álvarez (:emilio)]

The filter property creates a containing block for fixed-pos descendants, so the behavior described in comment 9 is actually expected.

It was changed in https://github.com/w3c/fxtf-drafts/issues/11 to affect the root element specially, I know there is a bug to update to the spec, but i can't find it right now... Do you know which bug is it?

Comment 12

[Markus Stange [:mstange]]

Bug 1423746