1413486 - Child element with z-index: -1 and filter is hidden behind the parent element's background

Status: NEW

(Core :: Web Painting, defect, P3)

Description

[Scott Wu [:scottwu]]

Attachment: filter-zIndex.html

While investigating an issue with autofilling credit card info on Booking.com, I found that a child element with any filter, combined with z-index < 0, will be hidden behind its parent element's background.

Chrome does it differently, and would not hide the child element, but I don't know what the spec says and who's doing it right.

This is important to Form Autofill because we put a filter rule on every element we perform autofilling. On Booking.com the filled month & year select element would disappear when we do it.

Comment 1

[Jonathan Kew [:jfkthame]]

It looks to me like we're wrong here (unless there's something I'm missing in the specs -- which is always a strong possibility!)

According to [1], "The z-index CSS property specifies the z-order of a positioned element and its descendants"; see also [2]. This fits with the description at [3], which refers to "...positioned descendants with negative z-indices..." (note the requirement to be "positioned").

But in the testcase here, the <select> is not a "positioned element" (i.e. its position property is static), and therefore z-index should not be applicable to it. I don't see why the presence of 'filter' should affect this.


[1] https://developer.mozilla.org/en-US/docs/Web/CSS/z-index
[2] https://www.w3.org/TR/CSS2/visuren.html#z-index
[3] https://www.w3.org/TR/CSS21/zindex.html#painting-order

Comment 2

[Milan Sreckovic [:milan] (needinfo for best results)]

Daniel, thoughts?

Comment 3

[Daniel Holbert [:dholbert] (vacation until Jun 23)]

(In reply to Jonathan Kew (:jfkthame) from comment #1)
> in the testcase here, the <select> is not a "positioned element" (i.e.
> its position property is static), and therefore z-index should not be
> applicable to it. I don't see why the presence of 'filter' should affect
> this.

"filter" (correctly) makes the <select> a *containing block* for abspos & fixedpos descendants, as noted in bug 1226095 comment 3.  But yeah, it's not positioned itself, so it seems incorrect to let "z-index" apply to it.

I'll bet when we decide "does z-index apply", we must be incorrectly treating "IsFixedPosContainingBlock" as a signal that this element is itself positioned, or something like that.

This is likely a bug in our display list construction code (or maybe layers?)  CJ, looks like you assigned yourself on bug 1226095 (though I'm not sure what needs to be done over there, since IIUC we're matching the spec in that case). Maybe you'd be interested in taking a look at this?

BTW, I tracked down the regression range, and this did indeed regress with bug 1125767 ("CSS/SVG filters on an element should make it a containing block for fixed-pos and abs-pos descendants.") Regression pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=58c9d079f318&tochange=42afc7ef5ccb

Comment 4

[u459114]

I read throught the comment in bug 1226095.

We induce a containing block for filtered absolutely and fixed positioned elements
https://drafts.fxtf.org/filter-effects/#FilterProperty
ISSUE 1 Should establish a containing block for values not-none for absolutely and fixed positioned elements. <https://github.com/w3c/fxtf-drafts/issues/11>

It's not relative to display list, instead, it's about the return value of HasFixedPosContainingBlockStyleInternal whe filter in not none:

template<class StyleContextLike>
bool
nsStyleDisplay::HasFixedPosContainingBlockStyleInternal(
                  StyleContextLike* aStyleContext) const
{
  // ...
  return aStyleContext->ThreadsafeStyleEffects()->HasFilters(); <<
}

Comment 5

[Firefox Bug Husbandry Bot]

https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Move_fix-optionals