Closed Bug 995813 Opened 6 years ago Closed 6 years ago

Content with SVG mask applied fails to render

Categories

(Core :: SVG, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla31

People

(Reporter: a.nomaly, Assigned: longsonr)

Details

Attachments

(6 files)

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.
Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago
Resolution: --- → INVALID
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.
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"
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: INVALID → ---
Attached image 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.
OS: Windows 7 → All
Hardware: x86_64 → All
Summary: SVG file is not entirely rendered → Content with SVG mask applied fails to render
Version: 28 Branch → Trunk
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.
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.
Attachment #8406273 - Attachment description: reference case 1 → reference case 1a ('fill' specified on rect inside mask)
Attachment #8406276 - Attachment description: reference case 1b → reference case 1b ('fill' specified via mask's style attribute)
Attached patch mask.txtSplinter Review
Since pattern and mask aren't graphics elements they need those bits.
Assignee: nobody → longsonr
Status: REOPENED → ASSIGNED
Attachment #8406472 - Flags: review?(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?
Attachment #8406472 - Flags: review?(dholbert) → review+
https://hg.mozilla.org/mozilla-central/rev/b5c65cbb4b1a
Status: ASSIGNED → RESOLVED
Closed: 6 years ago6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla31
(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?
(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 .
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.
You need to log in before you can comment on or make changes to this bug.