510177 - firefox 3.5 does not render svg path element with one point

Status: RESOLVED FIXED

(Core :: SVG, defect)

Description

[Schwed]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.2) 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

Comment 1

[Robert Longson [:longsonr]]

In which version did this work? Please upload a complete testcase using the Add an attachment link above.

Comment 2

[Robert Longson [:longsonr]]

Looks like this has come up before (bug 322976)

Comment 3

[Schwed]

Attachment: A test tfile. If you see a big black dot, everthink is ok.

Comment 4

[Robert Longson [:longsonr]]

In which version did this work?

Comment 5

[Schwed]

Definitely since FF 3.0, I'm almost sure in FF 2.0 it worked too.

Comment 6

[Jonathan Watt [:jwatt]]

Yes, this used to work in FF3.

Comment 7

[Robert Longson [:longsonr]]

Attachment: patch

Comment 8

[Jonathan Watt [:jwatt]]

Comment on attachment 409797 [details] [diff] [review]
patch

r=jwatt

Comment 9

[Robert Longson [:longsonr]]

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.

Comment 10

[Robert Longson [:longsonr]]

Attachment: updated patch

Comment 11

[Jonathan Watt [:jwatt]]

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.

Comment 12

[Robert Longson [:longsonr]]

Attachment: address review comment and add reftest

Comment 13

[Robert Longson [:longsonr]]

checked in but then backed out again as it may have caused a smil reftest failure.

Comment 14

[Robert Longson [:longsonr]]

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1261243023.1261245024.29438.gz&fulltext=1

Comment 15

[Robert Longson [:longsonr]]

Attachment: with bustage fix

Comment 16

[Robert Longson [:longsonr]]

pushed http://hg.mozilla.org/mozilla-central/rev/516b6b9daa30

Comment 17

[Phil Ringnalda (:philor)]

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.

Comment 18

[Robert Longson [:longsonr]]

Clearly is cursed as it didn't fail this mochitest last time it landed. It needs backing out.

Comment 19

[Daniel Holbert [:dholbert]]

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)