Bug 124269 - NPAPI plugins ignore savedData when calling NPP_Destroy and NPP_New
Summary: NPAPI plugins ignore savedData when calling NPP_Destroy and NPP_New
Alias: None
Product: WebKit
Classification: Unclassified
Component: Plug-ins (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
Depends on:
Reported: 2013-11-13 00:25 PST by Christian
Modified: 2013-11-13 23:37 PST (History)
5 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Christian 2013-11-13 00:25:35 PST

Initially I made some observations that led me to look deeper into the NPAPI specification to find out what the expected behaviour should be. The initial observations are:

1) I have a NPAPI video/mp4 object which is instantiated without the "data=".
2) Later on from javascript the "data" property is set and handled on the plugin.
3) Then I change the "className" (again from Javascript) of the object to change its size on the page.
4) This results in a reattachment of the element inside WebKit and the plugin is destroyed and instantiated again.

My problem is that when destroyed and initialised all context in the plugin is lost, and all fields (like "data") needs to be given to the plugin again. But this is not the case. Therefore, when having changed to the correct stylesheet it's not possible to start the video since the "data" field is not known.

From the NPAPI specification it's clear that NPP_Destroy and NPP_New should allow the use of "savedData" to store and re-store the state of a plugin. However this data is ignored in WebKit, e.g. see Source/WebKit2/WebProcess/Plugins/Netscape/NetscapePlugin.cpp where NPP_Destroy is called and the saved data is discharged immediately after.

Please refer to:

Best regards
Comment 1 Anders Carlsson 2013-11-13 10:08:59 PST
This has never worked in WebKit, and I'm pretty sure it doesn't work in any modern browser. Furthermore, now that plug-ins run in separate processes that can come and go at any time this isn't really feasible to implement. There are other ways for a plug-in to associate user data with a particular URL.
Comment 2 Christian 2013-11-13 23:37:53 PST
If this is the case, I think there still think there is the remaining problem that the plugins are destroyed and renewed and thereby loosing all context as I described.