SVG fails to render correctly

VERIFIED FIXED in mozilla1.9.3a1

Status

()

Core
SVG
P2
normal
VERIFIED FIXED
8 years ago
8 years ago

People

(Reporter: Damian Shaw [Quan], Assigned: Wan-Teh Chang)

Tracking

(5 keywords)

Trunk
mozilla1.9.3a1
regression, verified1.8.1.24, verified1.9.0.15, verified1.9.1, verified1.9.2
Points:
---
Bug Flags:
blocking1.9.2 +
blocking1.9.0.15 +
in-testsuite ?

Firefox Tracking Flags

(status1.9.2 beta1-fixed, blocking1.9.1 .4+, status1.9.1 .4-fixed)

Details

(URL)

Attachments

(1 attachment, 3 obsolete attachments)

(Reporter)

Description

8 years ago
Created attachment 403884 [details]
Wikimedia SVG

STR:

1. Open attached SVG
2. Observe Europe, Africa, the Americas and part of Asia display.

Actual result:

1. Only Europe renders correctly.

Could reproduce on:

Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2b1pre) Gecko/20090930 Namoroka/3.6b1pre (.NET CLR 3.5.30729) ID:20090930051755

Could not reproduce on Firefox 3.5 on Windows XP x64.
Flags: wanted1.9.2?
Flags: blocking1.9.2?
(Reporter)

Comment 1

8 years ago
Created attachment 403888 [details]
Incorrect rendering
(Reporter)

Comment 2

8 years ago
Created attachment 403890 [details]
Correct rendering
(Reporter)

Updated

8 years ago
Whiteboard: DUPEME
(Reporter)

Comment 3

8 years ago
Ignore the horizontal line at the top of the 2 images, just my poor screenshot taking ability.

Comment 4

8 years ago
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3

Same problem on Gecko 1.9.1.3/4pre on Windows XP SP 3.

Comment 5

8 years ago
Works:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a1pre) Gecko/20090925 Minefield/3.7a1pre

Fails:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a1pre) Gecko/20090926 Minefield/3.7a1pre

Regression range:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=def6be3d8b6b&tochange=149c3820e8a8

Comment 6

8 years ago
1.9.2 branch has same regression range.
Works:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2b1pre) Gecko/20090925 Namoroka/3.6b1pre
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/37595a72841c

Fails:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2b1pre) Gecko/20090926 Namoroka/3.6b1pre

Regression range:
http://hg.mozilla.org/releases/mozilla-1.9.2/pushloghtml?fromchange=37595a72841c&tochange=7a6b4aea8917

Perhaps, this is a regression from  Bug 414772 or bug 516396
http://hg.mozilla.org/mozilla-central/rev/ed8abff562ad
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/7a6b4aea8917

Comment 7

8 years ago
PR_strtod no longer accepts strings with >= 64K bytes following the check in for bug 516396

--- a/nsprpub/pr/src/misc/prdtoa.c	Fri Sep 25 18:22:48 2009 -0700
+++ b/nsprpub/pr/src/misc/prdtoa.c	Fri Sep 25 18:36:35 2009 -0700
@@ -1644,6 +1640,13 @@ PR_strtod
 
 	if (!_pr_initialized) _PR_ImplicitInitialization();
 
+	for(s = s00, i = 0; *s && i < 64 * 1024; s++, i++)
+		;
+	if (*s) {
+		PR_SetError(PR_INVALID_ARGUMENT_ERROR, 0);
+		return 0.0;
+		}
+

Here 64 * 1024 is 64 Kb and if the end of the string isn't found by then it gives up. In actual fact it needs to give up if anything that can't be part of a number (in this case a comma) is found.

Updated

8 years ago
Whiteboard: DUPEME

Updated

8 years ago
Blocks: 516396
Created attachment 404447 [details]
testcase with unnecessary stuff removed
(Reporter)

Updated

8 years ago
Attachment #403890 - Attachment is obsolete: true
(Reporter)

Updated

8 years ago
Attachment #403888 - Attachment is obsolete: true
(Reporter)

Updated

8 years ago
Attachment #403884 - Attachment is obsolete: true
(Assignee)

Comment 9

8 years ago
Robert: thanks for the explanation.  I got it now.  I will check in a fix soon.

Does SVG need to support a number longer than 64 * 1024 characters?
SVG has the same definition or <number> as CSS does:

http://www.w3.org/TR/CSS2/syndata.html#value-def-number

There are no special requirements for the number of digits in a number that should be supported, and I've not seen any content out there with stupidly large numbers of digits. There is a lot of tool generated content with crazy long "path" data though, which it seems reasonable to be able to throw that at PR_strtod.
(Assignee)

Comment 11

8 years ago
Could you test the NSPR patch in bug 516396 comment 57?  Thanks.

I just wanted to make sure PR_strtod can apply the 64K character limit
to just the number part of the input string.
That works great, thanks!

Comment 13

8 years ago
(In reply to comment #9)
> Robert: thanks for the explanation.  I got it now.  I will check in a fix soon.
> 
> Does SVG need to support a number longer than 64 * 1024 characters?

No, but a path is a collection of numbers. x, y, z, etc with seaparators that may be commas or letters. We parse the first number by sending the whole string to strtod then using the second strtod argument to find where to start to consume the next element.
blocking1.9.1: --- → ?
status1.9.1: --- → ?
Flags: blocking1.9.0.16?
Flags: blocking1.9.0.15?
OS: Windows Server 2003 → All
Hardware: x86 → All
Version: 1.9.2 Branch → unspecified
This regression should block the 1.9.1/1.9.0 releases
blocking1.9.1: ? → .4+
status1.9.1: ? → wanted
Flags: blocking1.9.0.16?
Flags: blocking1.9.0.15?
Flags: blocking1.9.0.15+
Assignee: nobody → wtc
Flags: wanted1.9.2?
Flags: blocking1.9.2?
Flags: blocking1.9.2+
Priority: -- → P2
This should be fixed, the change that caused this was (partially) backed-out from mozilla-central, 1.9.2 and 1.9.1 (bug 516396 comment 71). Marking "fixed1.9.0.15" because although the original patch hadn't yet landed there, we do want QA to verify that the revised patch doesn't cause this regression.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
status1.9.1: wanted → .4-fixed
status1.9.2: --- → beta1-fixed
Keywords: fixed1.9.0.15
Resolution: --- → FIXED
Verified fixed on trunk, 1.9.2, and 1.9.1 with builds on all platforms like:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.3a1pre) Gecko/20091006 Minefield/3.7a1pre ID:20091006031035

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2b1pre) Gecko/20091006 Namoroka/3.6b1pre ID:20091006034008

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.4pre) Gecko/20090924 Shiretoko/3.5.4pre ID:20090924030717
Status: RESOLVED → VERIFIED
Flags: in-testsuite?
Keywords: verified1.9.1, verified1.9.2
Target Milestone: --- → mozilla1.9.3a1
Version: unspecified → Trunk
Comparing 1.9.0.14 and 1.9.0.15 (build 3) on Windows Vista, the SVG image renders exactly the same on both.
Keywords: fixed1.9.0.15 → verified1.9.0.15
Calling this one "fixed1.8.1.24" to get some verification love: it was a regression from an early version of bug 516396's nspr patch which we have now taken on the 1.8.1 branch.
Keywords: fixed1.8.1.24
Verified for 1.8.1.24 using Seamonkey and attached SVG. It renders correctly now.

Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.24pre) Gecko/20100225 SeaMonkey/1.1.19pre
Keywords: fixed1.8.1.24 → verified1.8.1.24
You need to log in before you can comment on or make changes to this bug.