Created attachment 8460520 [details]
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.125 Safari/537.36
Steps to reproduce:
Open the attached file to view the repro.
When mix-blend-mode is used in conjunction with clip-path, the resulting colors are incorrect.
mix-blend-mode should correctly be applied regardless of whether clip paths are used. (NOTE: the mix-blend-mode experimental flag must be enabled).
Confirmed in 34.0a1 (2014-07-24), Win 7 x64
The first patch in bug 1279409 can "partially" fix the bug here. There are still another cause.
The painting result(the content of texture) is correct now. But the composition result of "#top_right" one is not right yet. I would suggest find a developer who is familiar with compositor to do further analysis. Deassign from myself.
Created attachment 8800148 [details]
Screenshot from 2016-10-12 16-29-12.png
After study, it's not compositor problem. I printed the layer tree in content and the blend mode of the layer was none.
So I traced back to ProcessDisplayItems. I found that for the wrong case, we create a temp BasicLayerManager and the layer created by nsDisplayBlendMode is contained in this BasicLayerManager. The PaintInactiveLayer result of the temp BasicLayerManager doesn't have the blend effect. The blend operation may be removed in bug 1279409.
Rendering result is not correct when nsDisplayMask contains a nsDisplayBlendMode child.
Why is the blend mode inside the mask? nsIFrame::BuildDisplayListForStackingContext should be creating the blend mode outside the mask.
Created attachment 8809462 [details]
Bug 1042296 - Part 1. Implement ShouldCopyBackground.
Review commit: https://reviewboard.mozilla.org/r/92040/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/92040/