Bug 35631
Summary: | Crash when attempting to render certain SVGs | ||
---|---|---|---|
Product: | WebKit | Reporter: | Tony Chang <tony> |
Component: | SVG | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED FIXED | ||
Severity: | Normal | CC: | krit, longsonr, simon.fraser, zimmermann |
Priority: | P2 | ||
Version: | 528+ (Nightly build) | ||
Hardware: | PC | ||
OS: | OS X 10.5 |
Tony Chang
The layout test attached to bug 35261 is also crashing on Leopard Intel Debug.
https://bugs.webkit.org/attachment.cgi?id=49654&action=prettypatch
The original bug is a fix for the crash in Skia, this bug is to fix the debug only crash in CG.
Attachments | ||
---|---|---|
Add attachment proposed patch, testcase, etc. |
Tony Chang
This test is now committed at svg/custom/tiling-regular-hexagonal-crash.svg, but skipped on mac.
Dirk Schulze
(In reply to comment #1)
> This test is now committed at svg/custom/tiling-regular-hexagonal-crash.svg,
> but skipped on mac.
What is the problem here? Changing Image might help but I would like to fix the real issue.
Dirk Schulze
(In reply to comment #2)
> (In reply to comment #1)
> > This test is now committed at svg/custom/tiling-regular-hexagonal-crash.svg,
> > but skipped on mac.
>
> What is the problem here? Changing Image might help but I would like to fix the
> real issue.
Ok, looks like the problem is a tile width or height of 0.
Dirk Schulze
Not only that we don't check for empty tile rects:
IntSize imageSize(lroundf(patternBoundariesIncludingOverflow.width()), lroundf(patternBoundariesIncludingOverflow.height()));
clampImageBufferSizeToViewport(document()->view(), imageSize);
OwnPtr<ImageBuffer> patternImage = ImageBuffer::create(imageSize);
it also looks like we have a parsing bug:
height=" 270"
We don't ignore leading zeros.
Simon Fraser (smfr)
Looks fine to me on SnowLeopard. Are there any remaining issues here?
Robert Longson
(In reply to comment #4)
>
> it also looks like we have a parsing bug:
>
> height=" 270"
>
> We don't ignore leading zeros.
It would be incorrect to ignore leading zeros. http://www.w3.org/TR/SVG/types.html#DataTypeLength
Dirk Schulze
(In reply to comment #6)
> (In reply to comment #4)
> >
> > it also looks like we have a parsing bug:
> >
> > height=" 270"
> >
> > We don't ignore leading zeros.
>
> It would be incorrect to ignore leading zeros. http://www.w3.org/TR/SVG/types.html#DataTypeLength
At first sorry for my typing error, I meant spaces instead of zeros. Nevertheless, you're right Robert.
<svg xmlns="http://www.w3.org/2000/svg">
<rect x="0" y="0" width=" 100" height="10" fill="red"/>
<rect x="0" y="20" width="100 " height="10" fill="red"/>
</svg>
Both, WebKit and Firefox, don't draw the rects. And this is correct according to the spec.
Dirk Schulze
The root of this problem was fixed. Closing the bug now.