995813 - Content with SVG mask applied fails to render

Status: RESOLVED FIXED

(Core :: SVG, defect)

Description

[LepidopTERA]

Attachment: Devolver Digital Double Debut.svg

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0 (Beta/Release)
Build ID: 20140314220517

Steps to reproduce:

Open provided graphic (Devolver Digital Double Debut) across different browsers (Internet Explorer and Firefox tested).


Actual results:

In Internet Explorer, all details in the SVG seem to render (where letters are the most glaring missing detail without comparison).


Expected results:

All details of the SVG (letters, details beyond font) should render.

Comment 1

[LepidopTERA]

Oddly, this seems to be fixed and may have been an issue with the originally uploaded SVG at https://www.humblebundle.com/devolver.  The SVG on that page now displays correctly, even though it did not for the duration of the debut.

The attached SVG still displays incorrectly, but as stated, may have an issue of its own that is beyond a problem with Firefox.

Comment 2

[LepidopTERA]

Attachment: Comparison of render between IE and FF

Comment 3

[Daniel Holbert [:dholbert]]

No need to resolve as invalid yet. The attached SVG may still demonstrate a Firefox bug.

(FWIW, Chrome renders the attachment the same way IE does.)

The missing features in Firefox are the paths with id "path-1" and "path-3". (If I remove those paths from the SVG, then Chrome's rendering changes to match Firefox.)  path-1 is the border around the logo; path-2 is the letters "I G" in "D I G I T A L"

Comment 4

[Daniel Holbert [:dholbert]]

Attachment: reduced testcase 1

In Chrome, this renders a small lime rect. In Firefox, the lime rect does not render (and so a red rect shines through).

I'm not very familiar with SVG masks, but this seems like a pretty basic usage of them not working.

Comment 5

[Daniel Holbert [:dholbert]]

Attachment: reference case 1a ('fill' specified on rect inside mask)

If I specify fill="white" on the rect inside the mask, instead of on the mask itself, then we render it correctly, as shown here.

Comment 6

[Daniel Holbert [:dholbert]]

Attachment: reference case 1b ('fill' specified via mask's style attribute)

Similarly, if I specify "fill" on the <mask> element in the style attribute (rather than via the 'fill' mapped attribute), then we render the mask.

Comment 7

[Robert Longson [:longsonr]]

Attachment: mask.txt

Since pattern and mask aren't graphics elements they need those bits.

Comment 8

[Daniel Holbert [:dholbert]]

Comment on attachment 8406472 [details] [diff] [review]
mask.txt

Ah, nice! Similar to bug 630657, I guess (where we added sGraphicsMap to SVGMaskElement::IsAttributeMapped()).

Before landing, could you either: 
 (a) add a testcase to prove that this is fixed for the pattern codepath, too
...or...
 (b) file a followup on doing that
...so that we don't regress this there?

Comment 9

[Robert Longson [:longsonr]]

https://tbpl.mozilla.org/?tree=Try&rev=08a7ac2d4d07

Comment 10

[Robert Longson [:longsonr]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/b5c65cbb4b1a

Comment 11

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/b5c65cbb4b1a

Comment 12

[LepidopTERA]

(In reply to Daniel Holbert [:dholbert] from comment #3)
> No need to resolve as invalid yet. The attached SVG may still demonstrate a
> Firefox bug.
> 
> (FWIW, Chrome renders the attachment the same way IE does.)
> 
> The missing features in Firefox are the paths with id "path-1" and "path-3".
> (If I remove those paths from the SVG, then Chrome's rendering changes to
> match Firefox.)  path-1 is the border around the logo; path-2 is the letters
> "I G" in "D I G I T A L"

Hey thanks for being so decent about it.  Being as this is the first report I've filed, I was a bit concerned with cluttering up the works with something unnecessary and getting some backlash over it.  So why does the current SVG at https://www.humblebundle.com/devolver not have this problem?

Also to anyone else, in layman's terms (if possible), what is being changed to make it work properly?

Comment 13

[Daniel Holbert [:dholbert]]

(In reply to LepidopTERA from comment #12)
> Being as this is the first report
> I've filed I was a bit concerned with cluttering up the works with
> something unnecessary and getting some backlash over it.

Understood.  Thanks very much for the bug report! You uncovered a real rendering bug, which Robert was excellent enough to fix immediately. :)

(Thanks especially for attaching the SVG file to the bug report. Without that, we wouldn't have been able to reproduce this anymore once the content on the humblebundle site changed, and we wouldn't have had any idea what had been wrong.)

> So why does the
> current SVG at https://www.humblebundle.com/devolver not have this problem?

This was a bug with <mask> rendering.

It looks like humblebundle changed the graphic to not use any <mask> elements at all (but instead just hardcoded paths, or something like that).

https://humblebundle-a.akamaihd.net/static/hashed/9a543aa3acc74eb0899e0793b61538dd0066c4b7.svg includes no mention of <mask>, at least.

> Also to anyone else, in layman's terms (if possible), what is being changed
> to make it work properly?

Basically, on <mask> elements, Firefox wasn't mapping the "fill" attribute (e.g. in <mask fill="white">) into the style system (CSS). So that "white" value wasn't inheriting down to the mask's children in the way that CSS says it should, and so the mask wasn't masking things in the way that it should, and that broke our rendering (making the mask block out too much).

Robert's patch makes us map that attribute (and a few others that he noticed were missing) into style, so now the inheritance will work correctly.

The fix landed in mozilla-central, which is currently at version 31, which will ship as Firefox 31 around July 22, according to https://wiki.mozilla.org/RapidRelease/Calendar .

Comment 14

[LepidopTERA]

In reply to your "Thanks very much for the bug report", I'll say I'm glad I was able to help.

Now I'll say thank you very much for the explanation on the SVG issue.  I really appreciate you taking the time to explain it in an understandable way.  Good luck with whatever you do moving forward!

Also, I'd be remiss if I didn't thank you, Robert, for pushing a fix.  Good luck to you as well.