<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#c17">Comment # 17</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#c11">comment #11</a>)
<span class="quote">> Regressions: Unexpected timeouts (1)
> plugins/npruntime/npruntime-calls-with-null-npp.html [ Timeout ]</span >
Ok, this is timing out because my patch changed the behavior. In current code we handle null npp in browser funcs, but in a slightly different way. NetscapePlugin::fromNPP() returns nullptr if the given instance is nullptr, and then PluginDestructionProtector does nothing if the instance is nullptr. So we end up actually calling the browser function on the given npobject even when the plugin instance is nullptr. With the new patch, we return early if npp is nullptr and the function returns false, which is not expected by npruntime-calls-with-null-npp.html. When fixing this I noticed that firefox always returns early from all the browser funcs when npp is nullptr, and I planned to check this also in WebKit in a follow up patch. I will update the test to make it work after this patch, and then I'll do the same for all other methods to keep consistency.
I also noticed that I should probably move browser-funcs-invalid-args.html to the npruntime subdir as well.</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>