1. http://www.celestron.com/browse-shop/astronomy/telescopes/cometron-firstscope 2. Assertion failure: !aInputMaskTransform.HasNonTranslation(), at c:/builds/moz2_slave/m-cen-w64-d-000000000000000000/build/src/layout/svg/nsSVGClipPathFrame.cpp:200 Nightly/45 all platforms but not Aurora/44. Reproduced with BuildID=20151127233401 https://hg.mozilla.org/mozilla-central/rev/7883e81f3c305078353ca27a6b1adb8c769d5904 I'll look for the regression range and see if I can't get a test case.

The first bad revision is: changeset: 272209:5515fd47eb5a user: Bas Schouten <bschouten@mozilla.com> date: Wed Nov 11 16:15:39 2015 +0100 summary: Bug 1210560 - Part 3: Convert more complex SVG usecases to PushGroupForBlendBack. r=jwatt r=jrmuizel

(In reply to Bob Clary [:bc:] from comment #2) > The first bad revision is: > > changeset: 272209:5515fd47eb5a > user: Bas Schouten <bschouten@mozilla.com> > date: Wed Nov 11 16:15:39 2015 +0100 > summary: Bug 1210560 - Part 3: Convert more complex SVG usecases to > PushGroupForBlendBack. r=jwatt r=jrmuizel Bas, jwatt could you take a look at this ? since its still reproducible with a latest build based on m-c

I swear Adobe Illustrator was written as an SVG fuzzing tool. The level of indirection used in this file is very high. I've been working on creating a reduced testcase but the complicated reference graph makes that slow going.

It looks like a scale is getting into this mask. MaskSurface only supports offsets. According to discussion with :jrmuizel, we can't use Mask here to work around it because DrawTargetCG doesn't currently support transforms on masks at all.

(In reply to Lee Salzman [:lsalzman] from comment #6) > It looks like a scale is getting into this mask. MaskSurface only supports > offsets. According to discussion with :jrmuizel, we can't use Mask here to > work around it because DrawTargetCG doesn't currently support transforms on > masks at all. But it is possible that we could add support for transforms to MaskSurface.

One thing I'd note is that the transform introduced by the width/height/viewBox combination is very sensitive to changes. Most values that I tried did not trigger the bug. That said, I had in mind that translation was the issue, so someone else may wish to experiment with scale in mind (make the values in the viewBox not match those of the width/height).

Copying my comment from bug 1252603 comment 7: We hit this code when we have both a mask and a clip-path on an element, which maybe explains why this isn't a common issue. The assert was originally added to the code in: https://hg.mozilla.org/mozilla-central/rev/5515fd47eb5a where it was !aInputMaskTransform.HasNonTranslation() (different argument name). Shame the assertion didn't add a string to explain what the issue is. :) However, the issue is that the DrawTarget::MaskSurface call that follows can only mask with an offset - a point which it gets from aInputMaskTransform - so if aInputMaskTransform contains anything other than a translation we are going to mask with the mask in the wrong position. In other words the result of failing this assertion should (just) be some mis-rendering. The value for aExtraMaskTransform can come from either of: https://mxr.mozilla.org/mozilla-central/source/layout/svg/nsSVGIntegrationUtils.cpp?rev=5dfa8eff77b6&mark=592-594#592 https://mxr.mozilla.org/mozilla-central/source/layout/svg/nsSVGMaskFrame.cpp?rev=e8c7dfe727cd&mark=259-260#259 In both case the Matrix includes the gfxContext's current transform, so we will fail this assertion if there is a non-translation in the transform to the root element (roughly speaking). I don't have time to fix this properly right now, but I'd be happy to change the assert to something less aggressive than MOZ_ASSERT.

bug 1258650 removed the assert.