I found that the current release of Lightspark (0.7.2) won't load in a browser running WebKitGTK 2.0.1. I ran in a debugger to see what was going on. Lightspark uses a newer version of NPAPI (NP_VERSION_MINOR = 27), while in WebKit we have NP_VERSION_MINOR = 24. Lightspark declines to load since it sees that the function table passed to it from WebKit is shorter than its own function table - this happens in fillNetscapeFunctionTable() in np_entry.cpp in Lightspark. Now, it would be nice if Lightspark were more compatible with older NPAPI versions, and I'll file a bug there too. But on the WebKit end it certainly would be nice to support the latest NPAPI, i.e. NP_VERSION_MINOR = 27.
See https://bugs.launchpad.net/lightspark/+bug/1158260 for a related bug report on the Lightspark side.
WebKitGTK 2.3.2 still has NP_VERSION_MINOR = 24.
@Adam: I understand that most major browsers will be dropping NPAPI support in the near future. If that is the case do you still feel this is a priority?
@Daniel: The practical goal here is to be able to use Lightspark (probably the best open-source Flash implementation) in WebKit-based browsers since many Web sites still rely on Flash, for better or for worse. NPAPI is the only way to do that today so yes, I'm still quite interested in this. Perhaps someday WebKit and Lightspark will both migrate to PPAPI, but I'm not convinced that will actually happen so soon. So I'd like to see the current API brought up to date even if it may not live forever.
I think I can take this one to work (I have solid experience with NPAPI plug-ins development). first off, let's clarify several questions : 1. is it necessary to fix only on WebKit side or ion Lightspark side or both? 2. for WebKit, basically it requires to upgrade WebKit from NP_VERSION_MINOR=24 to NP_VERSION_MINOR =27, that means to adding several API functions : - https://wiki.mozilla.org/NPAPI:AdvancedKeyHandling (NPN_HandleEvent, NPN_UnfocusInstance) - https://wiki.mozilla.org/NPAPI:HTTPRedirectHandling (NPP_URLRedirectNotify) since main goal is to get lightspark running in WebKitGTK, and none of these new APIs are actually in use by lightspark, and finally NPAPI negotiation allows to safely pass NULL or stubs, is it enough to just implement stubs in WebKit, or is it necessary to complete real implementations?
tomskside, I'm glad you're interested in working on this. I assume you're interested in the bounty I posted for this project at Bountysource: https://www.bountysource.com/issues/1335566-support-newer-npapi-so-lightspark-will-load To answer your questions: 1. To claim the bounty you only need to fix this on the WebKit side. If further work is necessary in Lightspark that would be a separate project. 2. I personally only really care about being able to run Lightspark, so I would be OK with having stubs for unnecessary functions. The WebKit developers may feel differently, however, and it is they who will decide if your implementation can land in WebKit (which is necessary for the bounty to be claimed). Would any of the WebKit developers like to comment on this?
I think NPAPI support is gone since Safari 14 and also from WebkitGTK port. I don't think this is supported anymore with webkit anymore. Can we close this bug as "RESOLVED INVALID"? Thanks!
<rdar://problem/95500581>
(In reply to Ahmad Saleem from comment #7) > I think NPAPI support is gone since Safari 14 and also from WebkitGTK port. > I don't think this is supported anymore with webkit anymore. Yup, "won't fix" it is.