User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:48.0) Gecko/20100101 Firefox/48.0 Build ID: 20160728204513 Steps to reproduce: Open http://preview.themeforest.net/item/creato-parallax-parallax-wordpress-theme/full_screen_preview/12170122 and notice it doesn't give the common "This site appears to use a scroll-linked positioning effect. This may not work well with asynchronous panning; see https://developer.mozilla.org/docs/Mozilla/Performance/ScrollLinkedEffects for further details and to join the discussion on related tools and features!" warning. In contrast, check these that trigger the warning: http://www.mercychurchnky.org/ http://www.fathershouseportland.org/ Actual results: Something must be wrong with the detection, as all the sites above use jQuery-stellar and change background positions on scroll. Could it be because the effects on the last two seem a millisecond or so slower? Is it detecting time taken on main thread? Expected results: It should be consistent. Also, the linked document should have some tips for how we are supposed to make Parallax effects without JS scroll detection (is that currently even possible with CSS?)

Warning was added by :kats in bug 1229052, let see if they have more details about this.

I think this is because on the URL in question the CSS change doesn't happen in the scroll event handler directly, it happens in a rAF call that is triggered by the scroll event handler. We are not able to reliably detect those cases, we only show the warning if the CSS change happens directly from the scroll handler. And yeah, the linked document should have some tips on how to do Parallax - right now it links to a blog post of mine [1] which does say how to do that, but we should inline that material. [1] https://staktrace.com/spout/entry.php?id=834

Note that there is some more discussion on this in bug 1276361. This bug is not quite a dupe of that one, but is similar in nature. There are a number of different ways to implement scroll-linked effects, not all of which we can detect. I'm not convinced it's worth the effort to catch the scroll-event-triggers-rAF-triggers-CSS-changes case, so I'm going to close this bug as WONTFIX. Even if we leave it open it's unlikely we'll fix it in the near future as we are working on other things so it'll likely just sit until it's obsolete.

are you saying changing the element in a rAF is still not optimal? Thanks for the link btw.

Yes, changing it in a rAF is about the same as changing it in a scroll event listener. In both cases it will be using the scroll position that the main thread has, as opposed to the scroll position visible to the user via the compositor.