This was uncovered in bug 1553828, after 3D transform bounds calculations were changed.
Matt says that this is a spec issue1:
- When we create a BlendItem, we also want the parent DL item to be a BlendContainer, and expect that to unconditionally work. That's why BlendMode is the last SC effect applied in BuildDisplayListForStackingContext, and BlendContainer is first
- When we do preserve-3d, we also want all the transform items to form a consecutive chain, but we know we can't do it unconditionally, which is why the spec (and nsIFrame::Extend3DContext) has a list of other effects that would break the chain, and thus disable preserve-3d
- The spec currently assumes only properties on the element with preserve-3d can matter, but in this case we have mix-blend-mode on the transformed child, which then forces a BlendContainer on the preserve-3d parent (and breaks the chain)
- It's possible that the ideal behaviour is that preserve-3d parents should not be a blend container, and we should put it on the first stacking context outside the preserve-3d context. We still have the issue that we have two types of chained effects, and we can't have them both consecutive (implementation limitation, seems solvable I guess)