1434196 - SVG path not rendered the same than Chrome/Safari

Status: RESOLVED DUPLICATE of bug 788361

(Core :: SVG, defect)

Description

[Karl Dubost💡 :karlcow]

This is the spin off of a webcompat issue. 
https://webcompat.com/issues/7588

Check this URI in Chrome/Safari and in Firefox.

data:text/html,<svg y="0" viewBox="0 0 100 100" x="0" width="70"><path xmlns="http://www.w3.org/2000/svg" d="M100 72.7c-.1 1.9-1.2 3.6-3.3 4.6-2.1 1-4.2.7-6.1-.8l-.6-.6c-5.1-5.1-10.2-10.2-15.4-15.3-7-7-14-13.9-21-20.9-2.2-2.2-5.2-2.2-7.4 0A26823030421658136 26823030421658136 0 0 0 5.5 78c-2.3-.1-4.1-1.2-5-3.3-1-2.1-.6-4.1.8-5.9.2-.3.5-.5.7-.8l44.2-44.2c2.4-2.4 5.2-2.3 7.6 0 4 4 8 7.9 12 11.9 8.8 8.8 17.6 17.6 26.4 26.3l6 6c1.1 1.2 1.8 2.6 1.8 4.7z"></path></svg>

In WebKit/Blink we get an upward arrow. In Firefox, something like the path has not been closed.

Comment 1

[Daniel Holbert [:dholbert]]

In Edge, we get something quite bizarre too (an arrow that looks a little like the chrome/safari one, but with a "growth" on the upper left edge). jsfiddle for testing in Edge: https://jsfiddle.net/x01y18s7/

I suspect this has to do with this path command with gigantic coordinates:
> A 26823030421658136 26823030421658136 0 0 0 5.5 78

Here's a reduced testcase that is just a triangle (horizontal 50, vertical 50, and then a close command) with this "arc" command interspersed:
data:text/html,<svg viewBox="0 0 100 100" height="100px" width="100px"><path xmlns="http://www.w3.org/2000/svg" d="M10 10 h50 v50 A26823030421658136 26823030421658136 0 0 0 5.5 78z"></path></svg>
https://jsfiddle.net/mx352v7p/

This reduced testcase renders:
 - a triangle in Chrome (as if the arc command weren't there)
 - nothing at all in Firefox (really probably something, but way outside the viewport)
 - some awkward stacked shapes in Edge.

Comment 2

[Daniel Holbert [:dholbert]]

Note that the coordinate used here, 26823030421658136, is approximately 2^54.


A few observations:
- If I modify the (non-huge) final "target point" of this arc command to (62,78) I can get *something* rendering in Firefox:
data:text/html,<svg viewBox="0 0 200 200" height="100px" width="100px"><path xmlns="http://www.w3.org/2000/svg" d="M30 30 h50 v50 A26823030421658136 26823030421658136 0 0 0 62 78z"></path></svg>
...and this also renders something (with 61.8 as x-coord):
data:text/html,<svg viewBox="0 0 200 200" height="100px" width="100px"><path xmlns="http://www.w3.org/2000/svg" d="M30 30 h50 v50 A26823030421658136 26823030421658136 0 0 0 61.8 78z"></path></svg>
...but this renders nothing (with 61 as x-coord):
data:text/html,<svg viewBox="0 0 200 200" height="100px" width="100px"><path xmlns="http://www.w3.org/2000/svg" d="M30 30 h50 v50 A26823030421658136 26823030421658136 0 0 0 61 78z"></path></svg>

So there's clearly some pathological behavior here with some pitfalls/discontinuities in our math that certain values can fall into.

Also, Chrome renders quite differently if I feed them a lower order-of-magnitude value for that huge point (using 2000000000, approximately 2^30):
data:text/html,<svg viewBox="0 0 100 100" height="100px" width="100px"><path xmlns="http://www.w3.org/2000/svg" d="M10 10 h50 v50 A200000000 2000000000 0 0 0 5.5 78z"></path></svg>
This implies that even their behavior for the huger value isn't correct -- because I expect an idealized rendering engine would really treat all points far off in the same direction ~equivalently, but clearly they don't.

So: I think there's clearly some integer overflow happening here -- these values are simply too large for *any* browser to handle gracefully/continuously.

Comment 3

[Daniel Holbert [:dholbert]]

Here's a version of the original URL with this bogus "arc-to" command (with massive rx/ry values) replaced with a simpler "line-to" command:
data:text/html,<svg y="0" viewBox="0 0 100 100" x="0" width="70"><path xmlns="http://www.w3.org/2000/svg" d="M100 72.7c-.1 1.9-1.2 3.6-3.3 4.6-2.1 1-4.2.7-6.1-.8l-.6-.6c-5.1-5.1-10.2-10.2-15.4-15.3-7-7-14-13.9-21-20.9-2.2-2.2-5.2-2.2-7.4 0L5.5 78c-2.3-.1-4.1-1.2-5-3.3-1-2.1-.6-4.1.8-5.9.2-.3.5-.5.7-.8l44.2-44.2c2.4-2.4 5.2-2.3 7.6 0 4 4 8 7.9 12 11.9 8.8 8.8 17.6 17.6 26.4 26.3l6 6c1.1 1.2 1.8 2.6 1.8 4.7z"></path></svg>

This renders consistently in Chrome and Firefox.

I think the most straightforward resolution here is to suggest that the authors use this ^^ instead.  The underlying issue here is probably not fixable (i.e. we probably can't promise any particular behavior for huge values, in the abstract) unless we had a graphics backend with infinite precision, which we do not.  (I believe we still use cairo under some configurations, for example, and it uses 24.8 fixed-point representation, so the largest value it can represent is 2^24 which is much less than the ~2^54 values used in the original testcase here.)

So I think this is effectively a dupe of bug 788361 (though at the high end of the representableness spectrum rather than at the low end).

Comment 4

[Karl Dubost💡 :karlcow]

Ah maybe Chrome is replacing the value by 0 or something close to 0 in face of humungus values.

if I do this, I get the right shape.

data:text/html,<svg y="0" viewBox="0 0 100 100" x="0" width="70"><path xmlns="http://www.w3.org/2000/svg" d="M100 72.7c-.1 1.9-1.2 3.6-3.3 4.6-2.1 1-4.2.7-6.1-.8l-.6-.6c-5.1-5.1-10.2-10.2-15.4-15.3-7-7-14-13.9-21-20.9-2.2-2.2-5.2-2.2-7.4 0A0 0 0 0 0 5.5 78c-2.3-.1-4.1-1.2-5-3.3-1-2.1-.6-4.1.8-5.9.2-.3.5-.5.7-.8l44.2-44.2c2.4-2.4 5.2-2.3 7.6 0 4 4 8 7.9 12 11.9 8.8 8.8 17.6 17.6 26.4 26.3l6 6c1.1 1.2 1.8 2.6 1.8 4.7z"></path></svg>

Comment 5

[Daniel Holbert [:dholbert]]

Yeah, I don't know what they're doing.

Their behavior on my reduced testcase in comment 1 suggests that they're **dropping the command entirely** (or something like that) -- because there, Chrome's not drawing *any* kind of line to the target (5.5,78) point there (which is a point at the lower-left of the SVG area), as you can see:
 https://jsfiddle.net/mx352v7p/

And you replace the giant coord with 0,0 in that reduced testcase, then Chrome (and Firefox) *do* draw a line to that lower-left point:
 https://jsfiddle.net/mx352v7p/1/

That's why I think they're just dropping the command, or something else bogus like that.  Hence, I don't think any browser does anything particularly "correct" with this giant arc command.