4

As you can see at Chromium project, Chrome/Chromium will unsupport NPAPI soon. So you can develop PPAPI based solution, ok.

I develop a web portal which use a NPAPI-plugin. Each time the portal is loaded (and perhaps chrome is updated) I need to know if the client browser stays compatible (i.e. NPAPI-capable).

In other words I would something like that:

// sub-methods
function isTheBrowserNpapiCapable() {
    // something I am searching
}

function displayTheNewPortal() {
    // install the PPAPI plugin if not present
    // do something ...
}

function displayTheRegularPortal() {
    // install the NPAPI plugin if not present
    // do something ...
}

// main code
if(isTheBrowserNpapiCapable()) {
    console.log("The browser stays compatible with the regular NPAPI plugin!");
    displayTheRegularPortal();

} else {
    console.log("Got it! NPAPI is definitively discarded. User must install the new PPAPI plugin");
    displayTheNewPortal();
}

I found "detect if chrome user has NPAPI active", "NPAPI not loaded in Chrome" or "detecting NPAPI using Javascript" but it does not help me. I am not intersested in knowing if my plugin is installed or not, but what is the right one (NPAPI or PPAPI) to install.

Someone has an idea to help me?

Regards

Community
  • 1
  • 1
OBS Conferencing
  • 171
  • 5
  • Why not simply switch over to PPAPI, when you have it ready? – Xan Jan 20 '15 at 12:08
  • I agree @Xan, it could be simplier. But it's an professional application which is already used by many customers. Switch to PPAPI for all could be risky and I have to study a more progressive way to convert customers. In this way, I could propose a _beta release (PPAPI)_ that users can install or not. – OBS Conferencing Jan 20 '15 at 13:47
  • You can't use PPAPI since you can't install a PPAPI plugin without either the Chrome team's permission or the user launching with special command parameters. The only exception to this is using PPAPI in NaCL, which isn't the same thing at all. – taxilian Jan 20 '15 at 17:36
  • Yes, but in my use case, the customers already installed the _NPAPI plugin_ months ago. They use browsers (Chrome and plugin) to work everyday. Chrome auto-update. So I need to programatically detect end-of-support for NPAPI. – OBS Conferencing Jan 21 '15 at 08:36
  • I tried `navigator.plugins` on Ubuntu/Chrome 37 expecting to get `undefined`. [See @smorgan last comment in this topic](http://stackoverflow.com/questions/19457786/npapi-support-in-firefox-and-chrome-actually-droped). But it returns a `PluginArray` :( – OBS Conferencing Jan 21 '15 at 08:39
  • What about enumerating navigator.plugins and looking for your specific plugin? If it is not there, it is either disabled, not installed, or NPAPI is not supported. You can maybe search for GoogleUpdate, because it is NPAPI as well and built into Chrome and I guess it should break, too (unless they create an PPAPI version at the same time...). Windows only, I think, if it matters. – PhistucK Jan 21 '15 at 10:29
  • See also http://stackoverflow.com/questions/28766423/detecting-npapi-support-in-chrome-using-javascript and http://stackoverflow.com/questions/14838739/detecting-npapi-support-using-javascript. (In short, the answer seems to be that you can detect whether a specific NPAPI plugin is installed, but not whether the browser supports NPAPI in general. Chrome seems to be pushing pretty hard to make any use of NPAPI untenable on the public web.) – Paul D. Waite Oct 26 '15 at 15:17
  • I did think that maybe if `navigator.plugins` had a length greater than zero, that might confirm that NPAPI *was* supported, but sadly Chrome seems to use the same array to list some non-NPAPI plugins (tested on Chrome 46 on my Mac), so that’s no good. – Paul D. Waite Nov 03 '15 at 15:26

0 Answers0