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) go to https://alvarotrigo.com/pagePiling/examples/horizontalScroll.html#page2 scroll Actual results: the slide flickers when the transition ends happens with or without WR Expected results: not so

2018-11-18T17:26:03: DEBUG : Starting merge handling... 2018-11-18T17:26:03: DEBUG : Using url: https://hg.mozilla.org/integration/autoland/json-pushes?changeset=201a77bfe3bcb4865627103273a532f0a6db955c&full=1 2018-11-18T17:26:05: DEBUG : Found commit message: Bug 1320608 - Make sure we wait for the next frame in the case where the animation started at the current frame. r=birtles MozReview-Commit-ID: 2j2yEzPHUJI 2018-11-18T17:26:05: DEBUG : Did not find a branch, checking all integration branches 2018-11-18T17:26:05: INFO : The bisection is done. 2018-11-18T17:26:05: INFO : Stopped

I can see InitialOverflowProperty assertions [1] in OverflowChangedTracker when the slide transition happens. I don't know what happens there. [1] https://hg.mozilla.org/mozilla-central/file/7e9cac76980a/layout/base/OverflowChangedTracker.h#l116

OK, this is actually caused by calling EffectSet::GetEffectSet(nsIFrame*) for the primary frame instead of style frame. We've been using the primary frame in various call sites of GetEffectSet.

FWIW, (actually I don't think it's worth), here is a patch to use the style frame in EffectSet::GetEffectSet() and FindAnimationsForCompositor(). I've confirmed that this patch actually fixes the flicker, but we should instead audit all call sites of these functions and pass the style frame in the functions.