User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:22.214.171.124) Gecko/20090729 Firefox/3.5.2 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:126.96.36.199) Gecko/20090729 Firefox/3.5.2 svg path element which consist only of one point (i.e. the d-attribute is like "M x,y Z") are no longer rendered. (Previous versions of FF has done it, also the Adobe svg viewer) Reproducible: Always Steps to Reproduce: 1.Create a svg file containing a path element like <path d="M x,y Z"/> where x, yare the coordinates of the point. 2.Examine the svg file withz FF3.5.2 3. Actual Results: You see nothing Expected Results: you should see a line consisting of one point
In which version did this work? Please upload a complete testcase using the Add an attachment link above.
Looks like this has come up before (bug 322976)
In which version did this work?
Definitely since FF 3.0, I'm almost sure in FF 2.0 it worked too.
Yes, this used to work in FF3.
Created attachment 409797 [details] [diff] [review] patch
Comment on attachment 409797 [details] [diff] [review] patch r=jwatt
Comment on attachment 409797 [details] [diff] [review] patch This is wrong. While you get some extents which allows drawing, they aren't the right ones.
Created attachment 410337 [details] [diff] [review] updated patch
Comment on attachment 410337 [details] [diff] [review] updated patch r=jwatt, but please expand the comment: // If 'extent' is empty, it's position will not be set. Although // GetUserStrokeExtent gets the extents wrong we can still use it // to get the device space position of zero length stroked paths.
Created attachment 418508 [details] [diff] [review] address review comment and add reftest
checked in but then backed out again as it may have caused a smil reftest failure.
Created attachment 418529 [details] [diff] [review] with bustage fix
Patch must be cursed, since the (previously unknown or at least unfiled) failure in test_smilTextZoom.xhtml in http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1261439943.1261442178.24825.gz looks suspiciously like you.
Clearly is cursed as it didn't fail this mochitest last time it landed. It needs backing out.
I think the mochitest is buggy actually. (I wrote it.) This is an issue similar to bug 535850 -- the test has animations that begin at time=1s, and it assumes that the "onload" handler will fire before those animations begin. However, in extreme cases, it looks like the onload handler takes longer than a second to fire, so we're already partway through our timeline when we get to it. This is a very low-probability random-orange. I'll push a fix for the test. (but even without the fix, it should probably go green in the next cycle)