Status

Under consideration.

Contributors

• Last modified: September 13, 2012
• Authors: Josh Aas (Mozilla Corporation)

Problem Summary

Some values provided via the NPN_GetValueForURL API can result in main-thread i/o (notably: NPNURLVProxy). The purpose of this proposal is to allow for asynchronous retrieval of values.

Current Proposal

The following NPAPI definitions will be added:

 typedef enum {
   NPNAsyncURLVProxy = 1
 } NPNAsyncURLVariable;
 
 NPError NPN_AsyncGetValueForURL(NPP instance, NPNAsyncURLVariable variable, const char *url);
 void NPP_AsyncReceiveValueForURL(NPP instance, NPNAsyncURLVariable variable, const char *url, char *value, uint32_t len);

Every successful request (returning NPERR_NO_ERROR) should result in a single availability callback, with value == NULL if there was a problem coming up with a value. The callback can be nested (immediate, occurring prior to the return of the request call to NPN_AsyncGetValueForURL).

The plugin would be responsible for freeing any callback result via NPN_MemFree.

The API will use a new async variable type in order to be clear about what values can/should be requested via the async API. Supporting the synchronous API variables via the async API would not make this clear. For example - Mozilla plans to require that proxy information be requested via the async API. A synchronous request would result in failure. Under this proposal, Mozilla can simply deprecate usage of NPNURLVProxy entirely, instead of insisting that it only be used in certain contexts.

This proposal does not cover non-URL-based values (NPN_GetValue) because we have not discovered a need for such an extension yet.

Open Issues

• None