1826481 - Incorect positioning of absolute elements with backdrop-filter

Status: RESOLVED INVALID

(Core :: Layout: Positioned, defect)

Description

[Josh]

Attachment: test page.

User Agent: Mozilla/5.0 (Windows NT 10.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36 Edg/109.0.1474.0

Steps to reproduce:

Use the test page bellow and compare the divs with backdrop filter to the ones without

Safari: Pass
Firefox: Fail
Chrome: Fail

Actual results:

the elements were positioned relative to the parrents.

Expected results:

Like the one without any backdrop-filter it should have appeared in the corner.

Comment 1

[Josh]

Attachment: Safari passing test

Comment 2

[Josh]

Attachment: Firefox Failing test

Comment 3

[Josh]

Attachment: Chrome Failing test

Comment 4

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

The Bugbug bot thinks this bug should belong to the 'Core::Graphics: WebRender' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 5

[Timothy Nikkel (:tnikkel)]

Unless I'm missing something, per spec it seems like Firefox and Chrome are correct here. From https://drafts.fxtf.org/filter-effects-2/#BackdropFilterProperty

"A computed value of other than none results in the creation of both a stacking context [CSS21] and a Containing Block for absolute and fixed position descendants, unless the element it applies to is a document root element in the current browsing context."

Comment 6

[Timothy Nikkel (:tnikkel)]

Is there something I missed that makes the Safari rendering the correct one? Thanks.

Comment 7

[Josh]

@Tim(In reply to Timothy Nikkel (:tnikkel) from comment #6)

Is there something I missed that makes the Safari rendering the correct one? Thanks.

Are you saying that webkit is wrong? Also I am not an expert in specs for web. it just seems weird cause its not mentioned in MDM. Also, somehow though, the behaviour is reversed with will-change: tranform :/

Comment 8

[Timothy Nikkel (:tnikkel)]

My reading of the spec suggests that webkit is incorrect here, but I am open to new information or corrections if I've missed something. I was wondering if you had additional information or reasoning that lead you to conclude that Safari was correct.

Yeah, MDN could be improved by mentioning that, I agree.

What do you mean the behaviour is reversed with will-change: transform? Can you provide a testcase to demonstrate what you are talking about?

Comment 9

[Josh]

Attachment: Will change transform

Comment 10

[Josh]

(In reply to Timothy Nikkel (:tnikkel) from comment #8)

My reading of the spec suggests that webkit is incorrect here, but I am open to new information or corrections if I've missed something. I was wondering if you had additional information or reasoning that lead you to conclude that Safari was correct.

Yeah, MDN could be improved by mentioning that, I agree.

What do you mean the behaviour is reversed with will-change: transform? Can you provide a testcase to demonstrate what you are talking about?

I meant will-change: transform; creates the same behavior (intended)

Comment 11

[Timothy Nikkel (:tnikkel)]

That seems expected as well. Transform creates a containing block, and will-change transform also needs to create a containing block as if the element did have a transform.

I'm going to resolve this as invalid as it seems like Firefox is following the spec. If there is something I've missed please reopen.

Comment 12

[Josh]

(In reply to Timothy Nikkel (:tnikkel) from comment #11)

That seems expected as well. Transform creates a containing block, and will-change transform also needs to create a containing block as if the element did have a transform.

I'm going to resolve this as invalid as it seems like Firefox is following the spec. If there is something I've missed please reopen.

Does that mean that the problem is webkit not creating a stacking context?

Comment 13

[Timothy Nikkel (:tnikkel)]

(In reply to Josh from comment #12)

(In reply to Timothy Nikkel (:tnikkel) from comment #11)

That seems expected as well. Transform creates a containing block, and will-change transform also needs to create a containing block as if the element did have a transform.

I'm going to resolve this as invalid as it seems like Firefox is following the spec. If there is something I've missed please reopen.

Does that mean that the problem is webkit not creating a stacking context?

That is my understanding, yes.