In Flash Player 7, we did not support NPRuntime. We supported the older-school XPConnect JavaScript interface. In FP8 we moved to support NPRuntime.
With a recent Deer Park, Flash Player 8r22 and the testcase attachment (note the other test case links were Forbidden to me for some reason), I see the following:
NPP_Initialize and NPP_New are called.
NPP_GetValue is called for NPPVpluginScriptableNPObject, which causes us to call NPN_CreateObject, which causes Deer Park to call NPObject::NPAllocate() on us. After this, we call NPN_RetainObject().
NPP_Destroy is called, and NP_Deallocate is called on the same NPObject we created above.
NPP_Shutdown is called.
If it helps, you can likely test this same blocker on the NPRuntime sample plug-in and get the same results, as we copied that sample as closely as possible, and we've reviewed our NPRuntime code with Brendan. But, we could potentially have a bug in Flash, of course.
From the Flash Player perspective...
In Flash Player 7, we did not support NPRuntime. We supported the older-school XPConnect JavaScript interface. In FP8 we moved to support NPRuntime.
With a recent Deer Park, Flash Player 8r22 and the testcase attachment (note the other test case links were Forbidden to me for some reason), I see the following:
NPP_Initialize and NPP_New are called.
NPP_GetValue is called for NPPVpluginScrip tableNPObject, which causes us to call NPN_CreateObject, which causes Deer Park to call NPObject: :NPAllocate( ) on us. After this, we call NPN_RetainObject().
NPP_Destroy is called, and NP_Deallocate is called on the same NPObject we created above.
NPP_Shutdown is called.
If it helps, you can likely test this same blocker on the NPRuntime sample plug-in and get the same results, as we copied that sample as closely as possible, and we've reviewed our NPRuntime code with Brendan. But, we could potentially have a bug in Flash, of course.