Closed Bug 1564071 Opened 4 months ago Closed 4 months ago

Element with position: sticky inside element with a filter scrolls with content

Categories

(Core :: Panning and Zooming, defect, P3)

67 Branch
Desktop
All
defect

Tracking

()

VERIFIED FIXED
mozilla70
Tracking Status
firefox-esr60 --- wontfix
firefox-esr68 --- wontfix
firefox68 --- wontfix
firefox69 --- verified
firefox70 --- verified

People

(Reporter: listenleser, Assigned: botond)

References

(Depends on 1 open bug, Regression)

Details

(Keywords: regression)

Attachments

(2 files)

Attached file sticky-filter-bug.html

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:67.0) Gecko/20100101 Firefox/67.0

Steps to reproduce:

  1. Open attached HTML file (which has a position: sticky element inside a filter: brightness(1) element).
  2. Scroll.

Actual results:

The sticky element scrolls with the content, and only jumps back to the bottom when you resize the window.

Expected results:

The sticky element should always be at the bottom, and not scroll with the content.

I can reproduce the issue on Nightlu69.0a1 Windows10 if disable WebRender

Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Unspecified → All
Product: Firefox → Core
Hardware: Unspecified → Desktop
Keywords: regression

Disabled APZ fixes the issue

Component: Untriaged → Panning and Zooming

I expect this has the same root cause as bug 1404218. See also bug 1418923 for relevant discussion.

Note that this bug does not affect WebRender; if enabling that is an option for you, that's the most effective workaround.

Depends on: 1404218
Priority: -- → P3
See Also: → 1418923

It also occurs to me that we mitigated the issue underlying bug 1404218 significantly in bug 1300864, but the mitigation does not apply to sticky elements. We may be able to extend the mitigation to apply to sticky elements as well.

Let's use this bug to track extending the mitigation to sticky elements.

Assignee: nobody → botond
Pushed by bballo@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/67d64b7bb76b
Disable paint skipping for scroll frames that contain a sticky element inside a CSS filter. r=mstange
Status: NEW → RESOLVED
Closed: 4 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla70

Is this something we should consider for Beta uplift?

Flags: needinfo?(botond)

I think we should.

Flags: needinfo?(botond)

Comment on attachment 9077165 [details]
Bug 1564071 - Disable paint skipping for scroll frames that contain a sticky element inside a CSS filter. r=mstange

Beta/Release Uplift Approval Request

  • User impact if declined: On some page structures containing a position:sticky element inside a CSS filter, scrolling can result in the position:sticky element moving even when it's supposed to stay fixed, and the incorrect rendering can persist for an arbitrarily long time, usually until further user interaction like a click.
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: No
  • If yes, steps to reproduce:
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Very simple patch, only affects an optimization, and very specific page structures.
  • String changes made/needed:
Attachment #9077165 - Flags: approval-mozilla-beta?

Comment on attachment 9077165 [details]
Bug 1564071 - Disable paint skipping for scroll frames that contain a sticky element inside a CSS filter. r=mstange

Disables an optimization which can cause incorrect rendering of position:sticky elements in some cases. Approved for 69.0b10.

Attachment #9077165 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

I have managed to reproduce this issue using Firefox 69.0b3 (BuildId:20190708182549) on Windows 10 64bit.

This issue is verified fixed using Firefox 70.0a1 (BuildId:20190805220030) and Firefox 69.0b10 (BuildId:20190801185445) on Windows 10 64bit, macOS 10.13.6 and Ubuntu 18.04 64bit.

Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.