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. Actual results: When mix-blend-mode is used in conjunction with clip-path, the resulting colors are incorrect. Expected results: 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
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
Assignee: cku → nobody
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.
You need to log in before you can comment on or make changes to this bug.