Open Bug 1650589 Opened 4 years ago Updated 2 months ago

Using <feColorMatrix> to increase contrast of alpha channel for svgs shows as transparent in <img> tag (regression)


(Core :: Graphics: WebRender, defect, P3)

79 Branch





(Reporter: cmbartschat, Unassigned)


(Blocks 2 open bugs)



(4 files)

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

Steps to reproduce:

Create a file called heart.svg with the following contents:

<svg xmlns="" viewBox="0 0 16 16">
<filter id='contrastAlpha'>
<feColorMatrix in="SourceGraphic"
values="1 0 0 0 0
0 1 0 0 0
0 0 1 0 0
0 0 0 1000 -500" />
<g filter="url(#contrastAlpha)">
<path d="M 1 8 l 6.9 6.9 l 0.2 0 l 6.9 -6.9 l 0 -3 l -2 -2 l -3 0 l -2 2 l -2 -2 l -3 0 l -2 2 z" stroke="#000" stroke-width="2" fill="none"></path>

When viewed directly, the svg displays correctly. However, when loaded in an <img> tag like:

<img src="heart.svg" style="outline: 2px solid red">

The image does not show up, only displaying the outline.

I'm on Windows 7, Firefox 79.0b3 (64-bit)

I used the mozregression gui (fantastic) which narrowed it down to:

Bug 1636482 - Allow WebRender on all versions of Windows. r=aosmond

Previously we were blocking older Windows and only allowing on Windows
10. This switches us to relying on the blocking to prevent WebRender
from riding the trains on Win7/8.

Differential Revision:

Actual results:

Nothing is displayed, as if the image is completely transparent.

Expected results:

There should have been a heart icon with a black stroke and no fill displayed, with only fully black and fully transparent pixels (no antialiasing) as a result of the color matrix.

The filter appears to work correctly with values up to "508 -254" in the place of "1000 -500", with "509 -254.5" being partially broken, and "510 -255" being fully broken.

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → Graphics: WebRender
Product: Firefox → Core

Using the svg from comment 0 either on it's own or inside an img, we used to display both, but in 2013 we stopped displaying both in this range

Bug 924102 and Bug 924103 seem like good candidates for this.

With webrender we used to display blank for both the svg and inside an img tag, but with this fix range we started drawing the svg (but not inside an img tag):

bug 1606742

I'm confused, are you saying that this svg wouldn't have been visible since 2013? It was completely fine for me up until yesterday in Firefox Developer Edition, and still displays correctly in the main version of Firefox.

I'm reporting what I saw on my system, it's seems like your system sees different results.

Ok, I understand. Please let me know if I can provide any additional information.

Blocks: gfx-triage
Severity: -- → S3
Priority: -- → P3

Can either of you reproduce this on Win7?

Flags: needinfo?(sotaro.ikeda.g)
Flags: needinfo?(rares.doghi)

Can you please attach the contents of your about:support as a text file?

Flags: needinfo?(cmbartschat)
Blocks: wr-80
No longer blocks: gfx-triage
Flags: needinfo?(cmbartschat)

(In reply to Jessie [:jbonisteel] pls NI from comment #9)

Can either of you reproduce this on Win7?

I saw the problem on win7 and on win10 with WebRender.

Flags: needinfo?(sotaro.ikeda.g)

I tried mozregression with the following command on my Win10 PC. But it did not work around regression range.

./mach mozregression --good 2018-03-01 --bad 2018-04-01 --pref gfx.webrender.all:true

I got the following range. The range is a bit wide because of the problem.

I was also able to reproduce this issue on Windows 7 as well in Beta 79.0b6 and our Nightly build 80.0a1 (2020-07-10) when WebRender is enabled.

Flags: needinfo?(rares.doghi)

Hey Nical - any thoughts on what could cause this issue?

Flags: needinfo?(nical.bugzilla)
Blocks: wr-81
No longer blocks: wr-80

@Nical: Ping

No longer blocks: wr-81
No longer blocks: gfx-82

Not actively looking at this, removing from our release metas.

No longer blocks: gfx-83
Flags: needinfo?(nical.bugzilla)
You need to log in before you can comment on or make changes to this bug.