1408230 - mix-blend-mode not work correctly when z-index is applied to a parent div

Status: RESOLVED INVALID

(Core :: Layout, defect, P3)

Description

[Asif Youssuff]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:58.0) Gecko/20100101 Firefox/58.0
Build ID: 20171012105833

Steps to reproduce:

As seen on reddit: https://www.reddit.com/r/firefox/comments/75yof5/does_mixblendmode_not_work_on_deeply_nested/

Visit: http://jsbin.com/keqeceseca/2/edit?html,css,output



Actual results:

	<div class="wrapper">
		<div class="demo wrapped"></div>
	</div>

div is displayed with a black background.


Expected results:

div should have the same background color specified in html background color, especially since there is no overlap of divs.

Comment 1

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Attachment: reporter's testcase

Comment 2

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

I'd need to read the spec pretty carefully to understand what's supposed to happen here.

Comment 3

[Darkspirit]

Attachment: Screenshot_20171021_024107.png

(In reply to David Baron :dbaron: ⌚️UTC-7 from comment #1)
> Created attachment 8918068 [details]
> reporter's testcase

Konqueror 4.14.25 @ Debian Testing:      blue body bg, both images have a white bg and black lines
Chromium 61.0.3163.100 @ Debian Testing: blue body bg, both images a black bg and white lines
firefox-esr 52.4.0 ESR @ Debian Testing: blue body bg, left image: white on blue + right image white in black
Nightly 20171020100426 @ Debian Testing: blue body bg, left image: white on blue + right image white in black

Comment 4

[Daniel Holbert [:dholbert]]

(In reply to David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla) from comment #2)

I'd need to read the spec pretty carefully to understand what's supposed to
happen here.

Same here -- though there's a new development -- nowadays Chromium matches Firefox here (they match the rendering shown on right half of comment 3's screenshot, which is still the rendering that Firefox has).

Given that they changed to match us, it seems much more likely than it originally did that our rendering is in fact correct (unless they happened to introduce the same bug that we have which is conceivable but unlikely).

Given that, there's less impetus to change to another behavior here; tentatively closing as INVALID since our behavior matches the dominant browser; but if anyone has got confidence that this behavior is in fact wrong and worth-changing, please reopen (perhaps while also filing a Chrome bug).