[Webkit-unassigned] [Bug 137425] Plugin process crashes in NPN_InvokeDefault

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=137425

Darin Adler <darin at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #293400|review?                     |review-
              Flags|                            |

--- Comment #28 from Darin Adler <darin at apple.com> ---
Comment on attachment 293400
  --> https://bugs.webkit.org/attachment.cgi?id=293400
Updated patch

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

> 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.

> 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?

> 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?

> 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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20161031/c3cf0af3/attachment.html>