1731575 - Don't use nsIScrollableFrame::IsScrollingActive when making decisions about what to send to the compositor about sticky position content

Status: RESOLVED FIXED

(Core :: Web Painting, enhancement)

Comment 1

[Timothy Nikkel (:tnikkel)]

Attachment: Bug 1731575. Don't use nsIScrollableFrame::IsScrollingActive when making decisions about what to send to the compositor about sticky position content. r?mattwoodrow,botond

nsIScrollableFrame::IsScrollingActive basically means "has this scroll frame been scrolled recently or is this the root scroll frame". Neither of which is relevant when we are async scrolling a scrollframe on the compositor.

What determines if we can scroll a scroll frame async is ScrollFrameHelper::mWillBuildScrollableLayer, aka nsIScrollableFrame::IsMaybeAsynchronouslyScrolled.

The code in nsDisplayStickyPosition::GetStickyScrollContainer already mostly neuters nsDisplayStickyPosition is this isn't the case, this just takes it one step further.

This also removes one more user of nsIScrollableFrame::IsScrollingActive, there are only a handful left.

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d3e28b05c8d6
Don't use nsIScrollableFrame::IsScrollingActive when making decisions about what to send to the compositor about sticky position content. r=mattwoodrow,botond

Comment 3

[Iulian Moraru]

https://hg.mozilla.org/mozilla-central/rev/d3e28b05c8d6