I have written a windowless NPAPI plugin which binds to a shared library for accessing my native resources. The plugin is loaded by a web Application running in Firefox browser.
Recently, I have seen in net, that using Java Script extensions, one can also make native code function calls.But these Java Script extensions are specific to browsers.
Can some one please tell me that if I use a Java Script extension instead of NPAPI plugin for calling my native code, will there be any performance improvement in terms of latency in making native library API calls?
Kindly note: My query is generic and not specifically for Firefox browser.
There is no generic answer to a question like this, the mechanisms implemented by different browsers have nothing in common.
Firefox: A native library can be called via js-ctypes. This mechanism should be more light-weight than the communication with an NPAPI plugin. Even more importantly, you don't have the overhead of inter-process communication (newer Firefox versions run plugins in separate processes).
Chrome: AFAIK the only way to access operating system functionality (such as writing files to a random location on disk) is via NPAPI, Chrome won't allow extensions to use system libraries. However, if you use a native library only to speed up execution and don't mind having this code run in a sandbox - the native client might work for you. Due to sandboxed execution it will probably be slower than an NPAPI plugin but it won't trigger huge scary warnings when your extension is installed.
Safari: From what I know, Safari doesn't let you use native libraries, not even via NPAPI plugins.
Internet Explorer: As of MSIE 9.0, Internet Explorer still doesn't have anything resembling JavaScript-based extensions.
Related
Recently after the latest chrome update version 42, NPAPI support was disabled by default in Chrome thus effectively dropping support for Silverlight, Java, Facebook Video and other similar NPAPI based plugins.As per the chromium developer docs we can temporarily re-enable NPAPI by overriding via
chrome://flags/#enable-npapi(Enable NPAPI). However this option will be there only till Sept 2015.They have also mentioned that this wait is for mission-critical plugins to make transition.
We are using an enterprise plugin and we have some dependency on chrome , to make the transition we have to re-implement the plugin.
What are the things we need to do for re-implementing and make it work for chrome, guys please shade some light on this.
It really depends on what exactly your plugin needs to do; FireBreath 2 is nearly ready and supports plugins in Chrome via native messaging, however:
For Chrome you must install an extension as well as installing the binary (the binary installer can trigger the extension install, but must be confirmed by the user)
There is no direct drawing model, so you'd need to use a javascript layer to draw and access it from the plugin
All APIs of FireBreath 2 plugins are now asynchronous.
FireBreath 2 is not quite ready, though you're welcome to help us get it ready.
Other options include Native Client, which has much better drawing support but is sandboxed, and Emscripten which allows you to compile C++ to javascript and is shockingly fast, but is also of course sandboxed. You could also write your own native messaging host to do what you need.
As #smorgan says, there is no one solution that is a drop-in replacement.
There is no general-purpose replacement that can do everything NPAPI plugins could do, so without knowing what your plugin does there's no way to answer that question.
You should look at the last section of the deprecation guide, and see if your plugin fits into one of the categories there. If not, you should post a specific question about what you want to accomplish.
Since I read Google's message that NPAPI will no longer be supported by the end of 2014, I've been looking for an alternative. The issue is that we currently use a custom made Kinect Browserplugin which we use to control the browser with JS and control Unity Web Player games with your body.
Without NPAPI support it simply won't work anymore and our work will be lost. Google gives NaCl as an alternative but this doesn't support interaction with hardware.
The main question I have is: How to use the Kinect in a webbased platform and crossbrowser?
Currently we have the "normal" Kinect and the Kinect One from the closed beta working in the browser and Unity Web Player.
Please share your thoughts on a solution.
I apologize in advance for just spewing out links without actually supplying much information, but as far as I know there are no known good alternatives.
If I was in your position, I would have a look at the chrome.usb API or possibly, depending on your use case, node-kinect.
Here's a good general resource/discussion of NPAPI alternatives: Browser Plugins in a post NPAPI world
Probably your best approach at this point is to continue using NPAPI except in Chrome, and in Chrome use native messaging. Of course, Chrome has made it as difficult as they can to install the host that you'll be connecting to, so it'll be a pain and you'll have to install the extension and the host seperately, but there you go.
I'm currently working on a web application I didn't build. My current mission is to make it cross browser compatible. It has certain requests written in ActiveX. My question is, is there a plug in, or short cut (per se) to make this application work in all modern browsers.
FireBreath is a C++ wrapper which gives you the possiblity to create a wrapper over an ActiveX, so they can be supported in other browsers.
Checkout http://www.firebreath.org/display/documentation/About+FireBreath
Ziv
It is not possible. ActiveX is a MSIE-only technique. You can safely assume that it will never be supported in any other browsers.
No, there isn't. It isn't really a feasible project anyway since ActiveX involves binary code that depends on Windows APIs. It would be difficult to get it to work on non-Windows platforms (WINE is far from perfect) and require architecture emulation to get it to work on non-x86 compatible platforms.
I'm trying both greasemonkey and Google's Chrome extensions. And found that Chrome seems to be using the same API names as GM. (I seem to be having the same bug...)
Just wondering whether greasemonkey is already a Google Chrome extension?
Yes, I believe you can just add Greasemonkey scripts and Chrome installs them as an 'extension' like all the other native extensions.
Checkout this article:
http://lifehacker.com/5461675/chrome-4-supports-greasemonkey-userscripts-without-an-extension
Note, however that some scripts seem to be supported on GreaseMonkey for Firefox only and can be a little buggy in Chrome. I'm not sure of the exact differences in implementation.
Simon.
#Simon pretty much hit it, but I wanted to make sure that this point is super-clear.
Google Chrome supports Greasemonkey scripts natively, using the same API so as to make existing scripts compatible. There's no Greasemonkey extension required.
Yes, Chrome supports userscripts but not fully as Greasemonkey. For example check out this userscript
Docs Online Viewer: http://userscripts.org/scripts/show/127774
It works well with Greasemonkey (in Firefox) but not with Chrome natively. There are many Greasemonkey functions that Chrome does not support yet.
I copy and paste a post from GreaseMonkey:
There is no greasemonkey extension for google chrome. What actually happened is chromium (the project which google chrome is based) developed it's own extension system and one component of that extension mechanism (probably inspired heavily by greasemonkey in the first place) works in almost exactly the same way (an external javascript interacting with a page purely through it's DOM) as greasemonkey. The chromium system uses a completely different api but effectively does the same thing. This large overlap in purpose and functionality combined with the popularity of greasemonkey on firefox meant they decided to implement the greasemonkey api (the majority of it anyway) natively within chromium. From there they went one step further and had the browser automatically wrap any greasemonkey scripts inside a chromium extension automatically and effectively made greasemonkey scripts a first class citizen.
Does the Android WebKit supports the XPCOM framework or NPRuntime API`s as like Firefox? How to implement JavaScript in the Android WebKit plug-in?
Update:
I am writing a media player plug-in for the Android WebKit browser and my plug-in needs to get the command from the web page through JavaScript (some actions like play/pause/stop/resize are issued as JavaScript commands from the browser). My plug-in is written in native C code. Are there any examples or sample plug-in available for JavaScript communication?
WebKit doesn't support XPCOM, as WebKit is entirely separate from the Mozilla stack.
When you say you want to "implement Javascript", what do you mean?
The built-in Android browser already supports the execution of Javascript.
The android browser supported NPAPI all the time, the mechanism changed in 2.1 though, now it looks for APKs with the intent filter "android.webkit.PLUGIN", so a plugin needs to be packaged separately.
Previously setting the plugin path on the WebView and compiling the plugin using the NDK did the trick.
Hope this helps, you will find a lot of info when googling for NPAPI and WebView or NPAPI and android.
Android's WebKit doesn't support XPCOM, nor does it support NPAPI and npruntime. Not sure how you're planning to write a browser plugin, but it's not going to be possible with the Android SDK.