Closed
Bug 976533
Opened 10 years ago
Closed 10 years ago
[CSS Blending] An element which has mix-blend-mode other than normal does not blend if it has a child which also has mix-blend-mode set
Categories
(Core :: Web Painting, defect)
Core
Web Painting
Tracking
()
RESOLVED
FIXED
mozilla30
People
(Reporter: olaru, Assigned: olaru)
References
Details
(Keywords: testcase)
Attachments
(5 files, 1 obsolete file)
590 bytes,
text/html
|
Details | |
35.89 KB,
text/html
|
Details | |
4.18 KB,
patch
|
roc
:
review+
|
Details | Diff | Splinter Review |
1.98 KB,
patch
|
Details | Diff | Splinter Review | |
39.67 KB,
image/jpeg
|
Details |
No description provided.
Assignee | ||
Updated•10 years ago
|
Summary: [CSS Blending] mix-blend-mode does not work when the element that has mix-blend-mode set has a child element which also has mix-blend-mode set → [CSS Blending] An element which has mix-blend-mode other than normal does not blend if it has a child which also has mix-blend-mode set
Assignee | ||
Comment 1•10 years ago
|
||
(In reply to Horia Iosif Olaru from comment #0) > Sorry for the lack of description. I accidentally pressed the return key... If we have an element with mix-blend-mode set to something other than normal, and this element has a child that also has a mix-blend-mode set, the child element blends correctly with the parent element. The parent element is no longer blended however.
Assignee | ||
Comment 2•10 years ago
|
||
Test case that reproduces the issue. The 'intermediate' class element does not blend with the 'parent' class element, and it should. When removing the mix-blend-mode property from the 'child' class, the 'intermediate' class element will blend with the parent.
Assignee | ||
Comment 3•10 years ago
|
||
Adding a paint dump. This issue seems to happen because of the way mix-blend-mode is implemented. When creating the display list for an element wich creates a stacking context, and also has a child wich has mix-blend-mode, the whole list for the stacking context creating element is wrapped in a BlendContainer item. This BlendContainer isolates blending, among other things. The parent element creates a stacking context because of having mix-blend-mode set, and is represented by a MixBlendMode item. Because this element also has a child element with mix-blend-mode set, and create a stacking context, it will also be wrapped in a BlendContainer item. In the attached dump, one ca see that the BlendContainer wraps the parent element MixBlendMode item. Since the BlendContainer isolates blending, it will likely also isolate its own MixBlendMode element. This seems like an unfortunate edge case of the BlendContainer based implementation, that might be solvable by making the MixBlendMode item alway wrap the BlendContainer. I need to test this though.
Assignee | ||
Comment 4•10 years ago
|
||
This issue depends on bug 952051 because, just like in bug 947121, an element with mix-blend-mode which in turn has a mix-blend-mode child, has an associated container layer that uses a surface.
Depends on: 952051
Assignee | ||
Comment 5•10 years ago
|
||
Attachment #8382735 -
Flags: review?(roc)
Assignee | ||
Comment 6•10 years ago
|
||
Attachment #8382736 -
Flags: review?(roc)
Comment on attachment 8382735 [details] [diff] [review] mix-blend-mode-nested.patch Review of attachment 8382735 [details] [diff] [review]: ----------------------------------------------------------------- ::: layout/generic/nsFrame.cpp @@ +2024,5 @@ > } > } > > + /* If adding both a nsDisplayBlendContainer and a nsDisplayMixBlendMode to the > + * same list, the nsDisplayBlendContainer should be added first. This only trailing whitespace
Attachment #8382735 -
Flags: review?(roc) → review+
Attachment #8382736 -
Flags: review?(roc) → review+
Assignee | ||
Comment 8•10 years ago
|
||
Removed trailing whitespace.
Attachment #8382735 -
Attachment is obsolete: true
Assignee | ||
Comment 9•10 years ago
|
||
Try run (including patches that fix the dependency bug 952051): https://tbpl.mozilla.org/?tree=Try&rev=e245c118706e
Updated•10 years ago
|
Assignee | ||
Updated•10 years ago
|
Keywords: checkin-needed
Comment 10•10 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/3bbd029605a2 https://hg.mozilla.org/integration/mozilla-inbound/rev/43137b4b4b2a
Flags: in-testsuite? → in-testsuite+
Keywords: checkin-needed
Comment 11•10 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/3bbd029605a2 https://hg.mozilla.org/mozilla-central/rev/43137b4b4b2a
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla30
Comment 12•10 years ago
|
||
I've tested this fix using the following environment: FF 32 Build Id:20140602072051 OS: Win 7 x64 But the bug doesn't seem to be fixed. I've attached a printscreen. It seems that the intermediate class has no effect.
Flags: needinfo?(cabanier)
Comment 13•10 years ago
|
||
I'm unable to reproduce the problem. What do you see here: http://codepen.io/adobe/pen/ac11eea3fe4b0ba55aa7e667afa51a3a
Flags: needinfo?(cabanier)
Comment 14•10 years ago
|
||
Sorry I got back so late to your request. There are 3 rectangles of different colors on a yellow background. I think it's working correctly now.
Updated•6 years ago
|
Component: Layout: View Rendering → Layout: Web Painting
You need to log in
before you can comment on or make changes to this bug.
Description
•