firefox 3.5 does not render svg path element with one point

RESOLVED FIXED

Status

()

Core
SVG
RESOLVED FIXED
8 years ago
8 years ago

People

(Reporter: Schwed, Assigned: longsonr)

Tracking

({regression, testcase})

unspecified
regression, testcase
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 3 obsolete attachments)

(Reporter)

Description

8 years ago
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
(Reporter)

Updated

8 years ago
Version: unspecified → 3.5 Branch
(Assignee)

Comment 1

8 years ago
In which version did this work? Please upload a complete testcase using the Add an attachment link above.
Component: General → SVG
Product: Firefox → Core
QA Contact: general → general
Version: 3.5 Branch → unspecified
(Assignee)

Comment 2

8 years ago
Looks like this has come up before (bug 322976)
(Reporter)

Comment 3

8 years ago
Created attachment 394471 [details]
A test tfile. If you see a big black dot, everthink is ok.
(Assignee)

Comment 4

8 years ago
In which version did this work?
(Reporter)

Comment 5

8 years ago
Definitely since FF 3.0, I'm almost sure in FF 2.0 it worked too.
Yes, this used to work in FF3.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression, testcase
OS: Windows XP → All
(Assignee)

Comment 7

8 years ago
Created attachment 409797 [details] [diff] [review]
patch
Assignee: nobody → longsonr
Attachment #409797 - Flags: review?(jwatt)
Comment on attachment 409797 [details] [diff] [review]
patch

r=jwatt
Attachment #409797 - Flags: review?(jwatt) → review+
(Assignee)

Updated

8 years ago
Blocks: 465996
(Assignee)

Comment 9

8 years ago
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.
Attachment #409797 - Attachment is obsolete: true
(Assignee)

Comment 10

8 years ago
Created attachment 410337 [details] [diff] [review]
updated patch
Attachment #410337 - Flags: review?(jwatt)
Attachment #410337 - Flags: review?(jwatt) → review+
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.
(Assignee)

Comment 12

8 years ago
Created attachment 418508 [details] [diff] [review]
address review comment and add reftest
Attachment #410337 - Attachment is obsolete: true
(Assignee)

Comment 13

8 years ago
checked in but then backed out again as it may have caused a smil reftest failure.
(Assignee)

Comment 14

8 years ago
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1261243023.1261245024.29438.gz&fulltext=1
(Assignee)

Comment 15

8 years ago
Created attachment 418529 [details] [diff] [review]
with bustage fix
Attachment #418508 - Attachment is obsolete: true
(Assignee)

Comment 16

8 years ago
pushed http://hg.mozilla.org/mozilla-central/rev/516b6b9daa30
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
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.
(Assignee)

Comment 18

8 years ago
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)
Depends on: 536444
(Assignee)

Updated

8 years ago
Blocks: 554013
You need to log in before you can comment on or make changes to this bug.