These are questions that bsmedberg found while trying to implement remoting for pieces of the NPAPI. I'd like to have tests and docs for these once the answers are known:
- NPN_GetURL and family have an optional target; does the behavior change if the target is null versus the empty string ""?
- Yes. If the parameter is NULL, the data is sent back to the plugin as a stream. If the parameter is "", the current window is replaced with the URL.
- NPStream has a url field; are there cases where this may be null? If so, would making it the empty string change the behavior?
- Do streams receieve a NPP_Destroy message before the associated instance is killed with NPP_Destroy? What reason code is given?
- Do url notifications receieve a NPP_URLNotify message before the associated instance is killed with NPP_Destroy? What reason code is given?
- Are there instances where making calls using NPRuntime is disallowed? (e.g. re-entering script from NPP_New can cause crashes in gecko)
- After NPP_NewStream is called, who owns the notifyData field of NPStream?
- Flash uses this field to store scratch data. Plugins should be allowed to store data and modify this field after the initial call to NPP_NewStream.
- npruntime.h seems to suggest that an NPClass' invalidate method is only called by the runtime, yet we seem to have code that handles the plugin calling it on browser-provided objects. What's the deal?
- May NPClass.setProperty be null? What is the expected behavior? Will the host throw an exception if webpage code attempts to set a property, or will it set a custom propery?
- May NPClass.invokeDefault be null?
- May NPClass.invoke be null? What is the expected behavior? Will attempting to call pluginobject.somefunction() fall back to calling .getProperty and .invokeDefault in sequence?
- Will the plugin host modify the NPClass structure passed in to NPN_CreateObject (e.g. to provide default behavior for null class pointers)? If not, can this be made a const NPClass*?