REGRESSION (r91125): Google Drawings is broken

• Component: SVG
• Status: RESOLVED FIXED

[Nico Weber]

1. Open this Google Drawing on Chrome Dev 14.0.835.0:
https://docs.google.com/drawings/d/1EkA4V3ZWvnB-Gt6MBItiwvQESavOXpPWhdtMVarG9aI/edit?hl=en_US

What is the expected result?
There should be a blue box in the center of the drawing

What happens instead?
Nothing is rendered. Google Drawings just doesn't work on the latest version of Chrome

Happens in webkit nighlies as well.

This is http://crbug.com/90629

[Rob Buis]

Maybe same problem as https://bugs.webkit.org/show_bug.cgi?id=64675
I posted an idea how to fix it on that bug.

[Nico Weber]

You say "chromium specific" in bug 64675. This problem here happens in the webkit nightlies as well.

[Rob Buis]

Hi Nico,

(In reply to comment #2)
> You say "chromium specific" in bug 64675. This problem here happens in the webkit nightlies as well.

Oops, good point! I looked briefly, but inspector seemed partly disabled and the markup is unreadable to me as-is. Is it possible for someone to make a reduced testcase?
Cheers,

Rob.

[Nico Weber]

Created attachment 102177 [details]
repro?

This might work as repro. I opened the devtools, clicked on the drawing, picked "Copy as HTML" in the context menu, and pasted that to a new file. The new file renders correctly in my current chrome dev channel, but not in the canary channel. It renders correctly in Ff4.

[Rob Buis]

Created attachment 102221 [details]
Patch

[WebKit Review Bot]

Comment on attachment 102221 [details]
Patch

Attachment 102221 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/9262147

New failing tests:
svg/custom/zero-path-square-cap-rendering2.svg

[Alexey Proskuryakov]

Comment on attachment 102221 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=102221&action=review

> Source/WebCore/rendering/svg/RenderSVGPath.cpp:156
>      // Spec(11.4): Any zero length subpath shall not be stroked if the âstroke-linecapâ property has a value of butt

Historically, non-ASCII text in code comments used to be breaking build on some platforms.

[Darin Adler]

Comment on attachment 102221 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=102221&action=review

>> Source/WebCore/rendering/svg/RenderSVGPath.cpp:156
>>      // Spec(11.4): Any zero length subpath shall not be stroked if the âstroke-linecapâ property has a value of butt
> 
> Historically, non-ASCII text in code comments used to be breaking build on some platforms.

Yup; we’ve avoided it for that reason.

[Rob Buis]

Landed in r91915.

[Csaba Osztrogonác]

The new test fails on GTK and on Qt platforms:
- http://build.webkit.org/results/GTK%20Linux%2032-bit%20Release/r91917%20%2815985%29/svg/custom/zero-path-square-cap-rendering2-pretty-diff.html

- http://build.webkit.org/results/Qt%20Linux%20Release/r91919%20%2835859%29/svg/custom/zero-path-square-cap-rendering2-pretty-diff.html

Have you got any idea why?

[Csaba Osztrogonác]

I skipped this test on Qt until fix: https://trac.webkit.org/changeset/91920