Bug 65257 - REGRESSION (r91125): Google Drawings is broken
Summary: REGRESSION (r91125): Google Drawings is broken
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: SVG (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Rob Buis
URL:
Keywords:
Depends on: 65317
Blocks:
  Show dependency treegraph
 
Reported: 2011-07-27 07:50 PDT by Nico Weber
Modified: 2011-07-28 07:38 PDT (History)
6 users (show)

See Also:


Attachments
repro? (3.87 KB, text/html)
2011-07-27 13:14 PDT, Nico Weber
no flags Details
Patch (6.16 KB, patch)
2011-07-27 19:31 PDT, Rob Buis
darin: review+
webkit.review.bot: commit-queue-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Nico Weber 2011-07-27 07:50:20 PDT
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
Comment 1 Rob Buis 2011-07-27 12:58:43 PDT
Maybe same problem as https://bugs.webkit.org/show_bug.cgi?id=64675
I posted an idea how to fix it on that bug.
Comment 2 Nico Weber 2011-07-27 13:04:03 PDT
You say "chromium specific" in bug 64675. This problem here happens in the webkit nightlies as well.
Comment 3 Rob Buis 2011-07-27 13:07:57 PDT
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.
Comment 4 Nico Weber 2011-07-27 13:14:32 PDT
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.
Comment 5 Rob Buis 2011-07-27 19:31:12 PDT
Created attachment 102221 [details]
Patch
Comment 6 WebKit Review Bot 2011-07-27 22:27:57 PDT
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
Comment 7 Alexey Proskuryakov 2011-07-27 22:53:10 PDT
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.
Comment 8 Darin Adler 2011-07-27 23:00:46 PDT
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.
Comment 9 Rob Buis 2011-07-28 05:47:32 PDT
Landed in r91915.
Comment 11 Csaba Osztrogonác 2011-07-28 06:16:13 PDT
I skipped this test on Qt until fix: https://trac.webkit.org/changeset/91920