User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/33.0.1750.154 Safari/537.36 Steps to reproduce: 1. Create an element inside SVG's defs element 2. Create any SVG filter 3. Reference the first element using svg:use 4. Apply the filter to the svg:use element, either by CSS or by attribute A simple test case is attached - it should display 3 rectangles, 2 red and 1 black. Chrome 33, Internet Explorer 11 and Firefox 13 display 3 rectangles. Firefox 28/29 display 2 rectangles only. Wrapping the svg:use element in an svg:g element and applying the filter on the svg:g element results in expected behaviour. Actual results: SVG filter is applied to the svg:use element Expected results: svg:use element disappears

Sorry, the expected and actual results are the other way around. Expected results: SVG filter is applied to the svg:use element Actual results: svg:use element disappears

svg.display-lists.painting.enabled = false fixes. Regressed by: Bug 776054

I debugged a similar bug a few months ago but I didn't complete it. It was something about certain SVG frames not including some offset in their transform, or something like that. There were three places where some frame types are special-cased when it comes to the meaning of their transform, and the special cases weren't consistent between the three places. Here's the wip patch I could salvage. I don't know if it works (and it doesn't apply since the nsSVGFilterFrame.cpp code has since moved to nsFilterInstance.cpp), but it's at least a starting point. I'm currently on PTO and won't be able to look at this in the coming one or two weeks, so if anyone else wants to, feel free.

This was fixed by bug 997735.