<html>
<head>
<base href="https://bugs.webkit.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_REOPENED "
title="REOPENED - Plugin process crashes in NPN_InvokeDefault"
href="https://bugs.webkit.org/show_bug.cgi?id=137425#c29">Comment # 29</a>
on <a class="bz_bug_link
bz_status_REOPENED "
title="REOPENED - Plugin process crashes in NPN_InvokeDefault"
href="https://bugs.webkit.org/show_bug.cgi?id=137425">bug 137425</a>
from <span class="vcard"><a class="email" href="mailto:cgarcia@igalia.com" title="Carlos Garcia Campos <cgarcia@igalia.com>"> <span class="fn">Carlos Garcia Campos</span></a>
</span></b>
<pre>(In reply to <a href="show_bug.cgi?id=137425#c28">comment #28</a>)
<span class="quote">> Comment on <span class=""><a href="attachment.cgi?id=293400&action=diff" name="attach_293400" title="Updated patch">attachment 293400</a> <a href="attachment.cgi?id=293400&action=edit" title="Updated patch">[details]</a></span>
> Updated patch
>
> View in context:
> <a href="https://bugs.webkit.org/attachment.cgi?id=293400&action=review">https://bugs.webkit.org/attachment.cgi?id=293400&action=review</a>
>
> > Source/WebCore/bridge/NP_jsobject.cpp:171
> > + if (!npp || !o || !o->_class || !o->_class->invokeDefault)
> > + return false;
>
> This is a change in behavior. Before we would return true with a void value
> in result when the invokeDefault pointer was null. I don’t see any test
> coverage for this change in behavior.</span >
Yes, this is not covered by tests, I'm afraid, I just copied the early return condition from firefox, but only null npp and null npobject is covered by the tests (I think, I'll check anyway).
<span class="quote">> > Source/WebCore/bridge/NP_jsobject.cpp:173
> > if (o->_class == NPScriptObjectClass) {
>
> This is broken now, because invokeDefault is null in NPScriptObjectClass, so
> this code will never run. No test coverage?</span >
Ah, I didn't notice that.
<span class="quote">> > Source/WebCore/bridge/NP_jsobject.cpp:213
> > + if (!npp || !o || !o->_class || !o->_class->invoke)
> > + return false;
>
> This is a change in behavior. Before we would return true with a void value
> for result when the invoke pointer was null. I don’t see any test coverage
> for this change in behavior.
>
> > Source/WebCore/bridge/NP_jsobject.cpp:215
> > if (o->_class == NPScriptObjectClass) {
>
> Also broken like the other case above.
>
> > Source/WebCore/bridge/NP_jsobject.cpp:293
> > + if (!npp || !o || !o->_class || !o->_class->getProperty)
> > + return false;
>
> This is a change in behavior. Before we would set result to a void value
> when the getProperty pointer was null. Maybe we should test this?
>
> > Source/WebCore/bridge/NP_jsobject.cpp:295
> > if (o->_class == NPScriptObjectClass) {
>
> Also broken like the other cases above.
>
> > Source/WebCore/bridge/NP_jsobject.cpp:322
> > - if (o->_class->hasProperty && o->_class->getProperty) {
> > - if (o->_class->hasProperty(o, propertyName))
> > - return o->_class->getProperty(o, propertyName, variant);
> > - return false;
> > - }
> > + if (o->_class->hasProperty(o, propertyName))
> > + return o->_class->getProperty(o, propertyName, variant);
>
> Why is it OK to drop the check of o->_class->hasProperty for null? Do we
> have a test case covering that?</span >
I went too fast and thought this was only checking getProperty and removed the if because getProperty was already null checked before.
<span class="quote">> > Source/WebCore/bridge/NP_jsobject.cpp:333
> > if (o->_class == NPScriptObjectClass) {
>
> Also broken like the other cases above.
>
> > Source/WebCore/bridge/NP_jsobject.cpp:408
> > if (o->_class == NPScriptObjectClass) {
>
> Also broken like the other cases above.
>
> > Source/WebCore/bridge/NP_jsobject.cpp:441
> > if (o->_class == NPScriptObjectClass) {
>
> Also broken like the other cases above.
>
> > Source/WebCore/bridge/NP_jsobject.cpp:522
> > if (o->_class == NPScriptObjectClass) {
>
> Also broken like the other cases above.</span >
I'll update the patch.</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>