Closed Bug 1280183 Opened 5 years ago Closed 3 years ago
Support position: fixed for contain: paint
'position:fixed' child element should position fixed relative to its containing box.
The jitter when scrolling is a chrome bug https://bugs.chromium.org/p/chromium/issues/detail?id=619999#c5
I think Firefox's behavior (with the contain pref enabled) is correct here, actually. The fixed position element should move, as you scroll the document. The "stay in this location as you scroll" behavior (which you're used to & expecting here) only happens because normally *the viewport* forms the containing block for fixed position elements. (And the viewport stays the same, when you scroll) But the containment spec explicitly says the the "contain" element (not the viewport) forms the containing block for fixed positioned descendants.  So, I don't see any spec justification for Chrome's behavior here (keeping the element in a constant position while you scroll the viewport). I'm pretty sure this is just a Chrome bug.  https://drafts.csswg.org/css2/visuren.html#fixed-positioning  https://drafts.csswg.org/css-containment/#containment-paint
(Could you clarify what exactly you think is wrong here, if you still think Firefox is doing something wrong?)
(In reply to Daniel Holbert [:dholbert] from comment #4) > (Could you clarify what exactly you think is wrong here, if you still think > Firefox is doing something wrong?) I'm not sure which behavior is right per spec, but I think it would be more useful if position:fixed could have a different behavior from position:absolute in this situation. and I noticed Firefox also behaves differently then Chrome for position:sticky.
Sticky position of the Firefox in the inline elements is not correct, I have found this problem yesterday.
(In reply to ziyunfei from comment #5) > I'm not sure which behavior is right per spec, but I think it would be more > useful if position:fixed could have a different behavior from > position:absolute in this situation. They *do* have (subtly) different behaviors in a version if this scenario. If the were more layers of wrapper-divs between the "contain:paint" container and the positioned descendant in question, and some of those wrappers were positioned as well, then the descendant in question would position differently depending on whether its abspos vs. fixed-pos. (An fixed-pos descendant would position with respect to the nearest fixed-pos containing block, i.e. the nearest contain:paint ancestor, or the viewport if there is none. An abs-pos descendant would position with respect to the nearest abs-pos containing block, i.e. the nearest positioned ancestor.) I'm not sure the spec actually intends for fixed-pos-within-contain:paint to be a particularly useful/fancy use-case. It's simply defined in simple terms, so that the contain:paint element can be painted independently of the rest of the page. Tab, can you confirm that Chrome's behavior here (shown in second half of attached screencast) is incorrect? I don't really understand what it's doing -- it almost seems like it's resolving "top" & "left" with respect to the "contain:paint" element, but then converting them to offsets from the viewport, and keeping it fixed with respect to the viewport as the contain:paint thing gets scrolled offscreen. Maybe there's some fixed-position codepath/optimization that's getting incorrectly activated there?
I can reproduce the position:sticky brokenness locally -- it gets fixed if I disable e10s, so I think it's an e10s-related (or async-pan-and-zoom-related) bug. I'll file that separately.
(I spun off bug 1280344 for the position:sticky brokenness. Turns out there's no dependence/relation to contain:paint there -- it's just a position:sticky bug.)
Per comment 3 and comment 7, Firefox's behavior here (with the contain about:config pref enabled) is what the spec requires. And Chrome's implementation has changed in the time since this bug was filed, such that it now matches the Firefox behavior in the attached screencast. So: resolving this as "invalid" since we're doing what's required, from both a spec & an interop perspective.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.