Closed Bug 1731575 Opened 3 months ago Closed 2 months ago

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

Categories

(Core :: Web Painting, enhancement)

enhancement

Tracking

()

RESOLVED FIXED
95 Branch
Tracking Status
firefox95 --- fixed

People

(Reporter: tnikkel, Assigned: tnikkel)

References

Details

Attachments

(1 file)

No description provided.
Depends on: 1728258

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.

Assignee: nobody → tnikkel
Status: NEW → ASSIGNED
Pushed by tnikkel@mozilla.com:
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
Status: ASSIGNED → RESOLVED
Closed: 2 months ago
Resolution: --- → FIXED
Target Milestone: --- → 95 Branch
You need to log in before you can comment on or make changes to this bug.