<html>
<head>
<base href="https://bugs.webkit.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - Using dpi unit in sizes attribute raises SIGSEGV"
href="https://bugs.webkit.org/show_bug.cgi?id=159412#c9">Comment # 9</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - Using dpi unit in sizes attribute raises SIGSEGV"
href="https://bugs.webkit.org/show_bug.cgi?id=159412">bug 159412</a>
from <span class="vcard"><a class="email" href="mailto:darin@apple.com" title="Darin Adler <darin@apple.com>"> <span class="fn">Darin Adler</span></a>
</span></b>
<pre>I am not sure the patch is OK. Seems a bit sloppy to turn any invalid value into CSS_UNKOWN.
What is the correct behavior when this kind of invalid value is specified for a source size? Should it be a parsing error? Should the size be silently omitted from the parsed result?
I looked at the original code before I fixed the storage leak. As far as I can tell, that original code still had the same issue. In the old code a null pointer dereference would happen inside the computeLength function in the SourceSizeList.cpp file.
<a href="https://trac.webkit.org/browser/trunk/Source/WebCore/css/SourceSizeList.cpp?rev=176719">https://trac.webkit.org/browser/trunk/Source/WebCore/css/SourceSizeList.cpp?rev=176719</a>
Assuming that we want to silently ignore the single size, I think the cleanest way to write the sourceSize function would be to have it return Optional<CSSParser::SourceSize> and return no source size at all when the value is invalid rather than instead using a size with a CSS_UNKNOWN primitive value in it.
The call site in CSSGrammar.y.in could just not append a size in that case.
But I am not sure what the desired behavior is in this error case.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>