1423746 - CSS 'filter' on the root element (documentElement) should not establish a containing block for absolute/fixed positioned descendants

Status: RESOLVED FIXED

(Core :: Web Painting, defect, P3)

Description

[Markus Stange [:mstange]]

This bug is about aligning with the spec change that was proposed at https://github.com/w3c/fxtf-drafts/issues/11#issuecomment-348046489 .

This involves:
 - Making the relevant change to the code that selects the containing block for an element
 - Making sure async scrolling works correctly with the display lists that can result from this change.

The async scrolling part is the tricky part. In order to give the scrolled nsDisplayFilter finite bounds with respect to the scrolled ASR even if the filter contains a fixed element, we need to add an additional scrolled clip inside the filter that applies to the entire contents of the filter, including the fixed element. I think that additional clip can be the rectangle nsFilterInstance::GetPreFilterNeededArea(scrolledFrame, rootScrollFrameScrollArea).GetBounds().

Comment 2

[Markus Stange [:mstange]]

The plan for this is currently being finalized in https://github.com/w3c/fxtf-drafts/issues/282 .

Comment 8

[Emilio Cobos Álvarez (:emilio)]

So in terms of fixing the frame tree shape here this is easy, and it's just a matter of adding:

if (aStyle.IsRootElementStyle()) {
  return false;
}

To somewhere around here.

But then presumably we need to propagate the root element's filters to the canvas somehow. Markus, do you know what the best way to do that is? Filters have various implications around clipping which I think you're most familiar with.

Comment 9

[Markus Stange [:mstange]]

I read up on this again. The way we specced this was not to propagate the root element's filters to the canvas. The root element filter should still be affected by scrolling, and it should not affect scrollbars. In other words, the place where we currently create the filter display item (BuildDisplayListForStackingContext for the block frame of the document element) is the right place to do it. We just need to insert an additional clip for that display item's contents, as mentioned in comment 0, to satisfy some internal consistency assertions.

Comment 12

[Emilio Cobos Álvarez (:emilio)]

Attachment: A test-case.

Behavior on other browsers doesn't seem to match comment 9... In particular, Both Blink and WebKit apply the filter to fixed pos elements (which shouldn't be applied per that comment otherwise), and the canvas background.

WebKit does something really really weird with the background though.

So it's kinda like the clip was transferred to the viewport frame, not the canvas frame. But, this filter doesn't apply to the root element's scrollbars, which is really odd and I wouldn't know how to implement if we propagate the filter to the root. I guess I could reduce the filter area somehow to not include the scrollbars? But that doesn't work on mac and android with overlay scrollbars...

Markus, thoughts? (when you're back :))

Comment 14

[adjenks]

I discovered what appears to be this bug and posted an example on stackoverflow here: https://stackoverflow.com/questions/67115220/why-does-filter-render-differently-in-different-browsers-on-the-html-and-body-ta

Comment 19

[Karl Dubost💡 :karlcow]

Setting Webcompat Priority to 1 because this is affecting Google Search.
https://github.com/webcompat/web-bugs/issues/95222

Comment 20

[Markus Stange [:mstange]]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #12)

Behavior on other browsers doesn't seem to match comment 9... In particular, Both Blink and WebKit apply the filter to fixed pos elements (which shouldn't be applied per that comment otherwise), and the canvas background.

So, I read up on it again, starting from this github comment.

Now I think the right place to insert the filter wrapper item is in the same place where we create the async zoom container, around here. This means that the filter will not scroll with the page contents, and it will apply to position:fixed elements, but it will not apply to scrollbars. And we need to make sure we put the page background color items in the right place: The html background color should be affected by a filter on the html element. For root content documents there will be an additional default background color (usually white) behind the filter.

Comment 21

[Emilio Cobos Álvarez (:emilio)]

Alright let me give that a shot!

Comment 23

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1423746 - Filter on root should not establish containing block for fixedpos elements. r=mstange

Teach nsDisplay{Filters,BackdropFilters} to use a style that doesn't
belong to mFrame for the root frame, and use it as needed.

Remove the BackdropFilters::CanCreateWebrenderCommands call because it
was testing for StyleSVGEffects::mFilters rather than mBackdropFilters,
so it was doing nothing.

Comment 24

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/fb4f887f5482
Filter on root should not establish containing block for fixedpos elements. r=mstange

Comment 25

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/8e3a271766ca
Annotate one test as fuzzy.

Comment 26

[Iulian Moraru]

https://hg.mozilla.org/mozilla-central/rev/fb4f887f5482
https://hg.mozilla.org/mozilla-central/rev/8e3a271766ca

Comment 27

[BugBot [:suhaib / :marco/ :calixte]]

Since the status are different for nightly and release, what's the status for beta?
For more information, please visit auto_nag documentation.