Under Aurora (FF16) and newer I'm seeing clipping taking place when viewing the following mask test cases and text zoom applied. Specifically I have one level of text zoom applied (i.e. Ctrl+0 followed by Ctrl++) http://dev.w3.org/SVG/profiles/1.1F2/test/harness/htmlObjectApproved/masking-intro-01-f.html http://dev.w3.org/SVG/profiles/1.1F2/test/harness/htmlObjectApproved/masking-mask-01-b.html http://dev.w3.org/SVG/profiles/1.1F2/test/harness/htmlObjectApproved/masking-opacity-01-b.html http://dev.w3.org/SVG/profiles/1.1F2/test/harness/htmlObjectApproved/masking-path-01-b.html http://dev.w3.org/SVG/profiles/1.1F2/test/harness/htmlObjectApproved/masking-path-11-b.html Looks fine in Beta (FF15). I suspect this is not just isolated to text zoom but other transformations since I see similar problems by navigating to: http://people.mozilla.org/~bbirtles/pres/fxdevcon-2012/#14.3 And then pressing the right arrow (to advance to the next bullet point). In this case the SVG has a scale transform applied to it. For this final test case if I Alt+Tab back and forwards the result is correct suggesting this is an invalidation bug and perhaps unrelated?

This regressed when the patch for bug 766429 was checked in, so it looks like we're not calculating the correct visual overflow rect for masks when zoomed in.

(In reply to Brian Birtles (:birtles) from comment #0) > I suspect this is not just isolated to text zoom but other transformations > since I see similar problems by navigating to: > http://people.mozilla.org/~bbirtles/pres/fxdevcon-2012/#14.3 > And then pressing the right arrow (to advance to the next bullet point). > In this case the SVG has a scale transform applied to it. > > For this final test case if I Alt+Tab back and forwards the result is > correct suggesting this is an invalidation bug and perhaps unrelated? I've split this off into separate bug 779403 as requested.

Seems like this is fixed in svg.display-list.painting.enabled is set to true (now the default), but broken when set to false. Not sure if this is worth tracking down for FF16 given than zooming is required to trigger the bug. Maybe we should just wontfix this?

Not sure about wontfixing, but we agree that this use case seems uncommon. Untracking for release.

I'm not sure if it's quite the same root cause but I'm seeing somewhat similar issues rendering the Firefox logo on FF16 with direct 2D enabled even without any text zoom applied: http://upload.wikimedia.org/wikipedia/en/e/e3/Firefox-logo.svg

The issue with the Firefox logo is that the path representing the countries towards the top of the planet has a clip path applied and the clip path region seems to be incorrect. On my work PC the entire path is clipped and on my home PC only the right two-thirds of the countries appear. The left-hand third is clipped.

Rendering on FF16 with direct2d enabled.

Oh, I just realised that the FF logo still renders incorrectly with svg.display-list.painting.enabled set to true and direct2d enabled so this is a separate bug.

(In reply to Brian Birtles (:birtles) from comment #12) > Oh, I just realised that the FF logo still renders incorrectly with > svg.display-list.painting.enabled set to true and direct2d enabled so this > is a separate bug. Filed bug 797231.

In which release did svg.display-list.painting.enabled start defaulting to true? I still see this bug in FF16.

Seems to work now.