1762089 - mix-blend-mode not working as expected when applied to svg elements inside of transformed <g> tags.

Status: RESOLVED DUPLICATE of bug 1379524

(Core :: SVG, defect)

Description

[petterssonalbin]

Attachment: bug_firefox_mixmultiply.svg

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:98.0) Gecko/20100101 Firefox/98.0

Steps to reproduce:

Create an SVG file. Add an element with some color, for example a square covering the entire area with fill set to blue.

Then define an svg element inside of a transformed <g> tag and give the element a class or id.

Then style that component using a <style> tag, and set it's mix-blend-mode to multiply and its fill color to a gray color.

<?xml version="1.0" encoding="UTF-8"?>
<svg width="100" height="100" version="1.1" viewBox="0 0 100 100" xmlns="http://www.w3.org/2000/svg">
<style>
.mix-mult {
fill: #bbbbbb;
mix-blend-mode: multiply;
}
</style>

<!-- Background -->
<rect width="100%" height="100%" fill="blue" />

<!-- Top Right -->
<g transform="translate(50 0)">
<rect width="50%" height="50%" class="mix-mult" />
</g>
</svg>

The same issue seems to arise with some additional (all?) blend modes. The same issue also seems to arise no matter which transforms are applied to the surrounding <g> tag, as long as it is transformed.

I'll attach a file which shows the issue. It renders as expected on both Chrome and Opera.

Actual results:

The element (in this particular example the element with its class set to mix-mult) is rendered as gray.

Expected results:

The element (in this particular example the element with its class set to mix-mult) should have been multiplied with the background, in this case resulting in a darker shade of blue.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::SVG' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Daniel Holbert [:dholbert]]

Thanks for the bug report.

Looks likely to be the same core issue as bug 1379524. (The testcase there involves an animation instead of a transform, but per bug 1379524 comment 1, setting a transform (or will-change:transform) triggers the same issue, which seems to be what the testcase here is doing.)