I tried both npapi and firebreath, but all of them only work well on Firefox, and easily stuck on Chrome . the function I wrote in plugin is the simplist "return 0;". i processed the Xemd case.
NPError NPP_GetValue(NPP instance, NPPVariable variable, void *value)
{
...
switch (variable) {
case NPPVpluginNeedsXEmbed:
*((BOOL*)value) = TRUE;
...
}
I'm not sure what versions you are using; Chrome discontinued support for NPAPI plugins (supported by FireBreath 1) in 2014; Firefox discontinued support for NPAPI plugins in Firefox 52, though I believe there was a LTS version of firefox 52 which continued to support them for another year and a half (which is likely over by now).
In short, NPAPI is pretty much dead -- the last holdout in generally used browsers is Safari and it's going away with the release of macOS Mojave.
There is a way to write a firebreath 2 plugin and make it work via native messaging but it's a bit of a complicated process and it's not super well documented; you can find information on the firebreath-dev google group and ask clarifying questions there.
Problem solved when I tried with chrome version 22. Higher version may also work.
It's not easy to find such an old version ,I'm afraid my plugin will never be used.-_-||
Related
I have a web application that I create on Nuxt.js, But I have noticed that there are compiling bugs in some of the browsers (Like Safari, IE), I think this is the fault of the Babel configuration, then i run npm run build ES6 is not compiled, and I have errors in my console
for cross-browsing testing, I am using Browserstack
I have following errors in the console:
Unexpected token '...'. Expected a property name
SyntaxError: Unexpected keyword 'const'. Const declarations are not supported in strict mode.
How can i configure Babel to compile ES6?
Apparently, your code is not working on Safari v10 and below. Looking at some stats here:
https://gs.statcounter.com/browser-version-partially-combined-market-share#monthly-202007-202107
https://www.w3schools.com/browsers/browsers_safari.asp
https://caniuse.com/?search=flex
https://en.wikipedia.org/wiki/Safari_version_history#Safari_10_2
It looks like Safari is used with a minority of versions but those are mostly v13 and v14. Those are far more modern then then one you do not support.
Safari v10 is actually from 2007, so I can think that it's safe to say that you can ditch this version totally.
Even if Safari is not an evergreen browser (meaning updating-itself like Firefox or Chrome), people still using it are not on that old of a version.
You need to remember that if you want to support a version that old, you will heavily impact the overall performance of the whole website for every user. Okay, 0.5% of people will have a better experience (those stuck in 2007) but everybody else will need to carry the weight of that old babel-transpiled version.
You could make 2 bundles (one modern and for super old legacy browsers) and serve either one or the other depending if they do support ES modules. I cannot find the Google/HTTP 203 talking about this one.
But IMO, this is a lot of work (not that trivial) for a super tiny population, I'd rather pass on this and focus on more important things to handle.
Even a11y is reaching more people. Even tho, it's probably on a lower priority than Safari v10.
Here are my 2cts. If I find the video, I may update my answer.
Hello as you might now NPAPI is deprecated.
What are the alternatives to this? I see skype released now the web version where you need to install a web plugin to make voice and video calls. Looking over what I installed I arrived to the conclusion that on chrome they are using Google Native Client: https://developer.chrome.com/native-client
But this one is not supported on firefox/safari (only chrome).
On Firefox/Safary I'm not sure what they are using.
So what are now the best alternatives for this kind of job where using c++ is mandatory (to extend an existing app and make it available as web plugin)
Silviu
After Chrome drop the NPAPI support, there is no-common technology support by Firefox/Chrome/Safari. You can consider about Firebreath 2.0. It allow you use one C++ implement to support different browser.
It's not released yet... If you like to try version 2.0, you can get source code from https://github.org/firebreath/firebreath (the "refactor" branch)
Note: version 2.0 make huge change, because the call between plugin and javascript are asynchronous! Upgrade from older version required lots of javascript change.
I am about to start work on a Mozilla plugin for my company's main product line. I was under the impression that I could build using the Gecko SDK, say two major revisions ago, and that would cover any browser a person would reasonably be using. I am also assuming that this will also cover Chrome and Opera (fact check someone?).
However, I was just reading the documentation and I found this:
For Gecko versions before 2.0, you should choose the Gecko SDK version for the earliest version of Mozilla you wish to target. For Gecko versions 2.0 and higher, you must recompile your component for each release as cross-version compatibility is no longer supported.
Someone please tell me this doesn't mean what I think it means. Does this mean that I am going to have to recompile my plugin for each version of Gecko indefinitely--even after deployment? That doesn't seem like something that the great team over at Mozilla would inflict upon us.
The Gecko SDK has at least two very different purposes. To quote the documentation:
The Gecko SDK, also known as the XULRunner SDK, is a set of XPIDL files, headers and tools to develop XPCOM components which can then in turn e.g. be accessed from XUL using JavaScript.
...
The Gecko SDK contains all of the necessary tools and headers for making scriptable NPAPI plugins including the xpidl compiler/linker and the latest npapi.h.
The sentence you quote from this page applies to the main purpose of the SDK: build native XPCOM components that can be used by Firefox extensions. These XPCOM components have access to browser's internal interfaces which brings up the question of interface stability. Starting with Gecko 2.0 (Firefox 4) this issue is solved in such a way that an XPCOM component can work with one Firefox version only. To work with a different Firefox version it needs to be recompiled with a newer version of the Gecko SDK.
The documentation doesn't really make it clear but all this doesn't apply to NPAPI plugins which communicate with the browser via fixed interfaces only. I'm not sure how much of the Gecko SDK is still needed to compile NPAPI plugins, it seems that it's only npapi.h and a few other header files. This file don't exactly change often, the changes are mostly limited to constants. So there are no problems compiling your plugin against an older SDK version - only side-effect is that you might not be able to use the new NPAPI features.
That said, you should be able to use NPAPI SDK instead of the Gecko SDK. It is a much smaller download and is dedicated explicitly to creating NPAPI plugins. The files in the Gecko SDK are essentially copied from the NPAPI SDK anyway (note the "Sync to npapi-sdk rNN" changes in the file history).
I know that if I write a C++ plugin, then I need to have Linux, Mac, Windows versions at least but what's the full list of combinations? NPAPI is supported by many browsers so does that mean the exact same compiled NPAPI plugin binary/installer/whatever for Windows is ready for use in all those browsers on Windows which support NPAPI? Or do you have to 'compile' the same plugin code separately for each browser in some way?
Yes, a single NPAPI plugin runs in every NPAPI-supporting browser on a given platform, as long as you don't do anything to specifically undermine that (e.g., some people make NPAPI plugins but then add XPCOM code to them, making them Firefox-specific).
Additionally, as you probably saw in the answer to your other question, FireBreath can be used to create a single plugin that can be made to work cross platform on pretty much all browsers, including IE on windows.
FireBreath strongly discourages using things like XPCOM for exactly the reason that smorgan mentioned.
Edit: The bug that caused this problem has been fixed. The #version tag now works in the stable release. See Issue 30760
Hey.
I've been wondering how I might set the version number displayed for user-scripts in Chrome's extension tab
(source: advefir.com)
So far the obvious methods have failed:
// ==UserScript==
// #version 1.1.5
// #uso:version 1.1.5
// ==/UserScript==
I know Greasemonkey for Firefox doesn't use a version value, but since Chrome actually displays a version number, I thought it might.
Perhaps this is a feature that has not been implemented?
Or maybe it was never intended to be there, but it is there because extensions have version numbers, and user-scripts are currently installed as extensions?
(I'm using the Linux beta, version: 4.0.249.43, by the way)
Thanks.
Ok, this appears to be a confirmed bug now. (Issue 30760)
Seems the standard #version meta-data is the correct usage, but it has not yet been implemented.
Edit: The #version tag now works in the stable release of Chromium (and, therefore, Chrome).
Or maybe it was never intended to be there, but it is there because extensions have version numbers, and user-scripts are currently installed as extensions?
I think so.
Version number used for updating extensions. User scripts currently can not update. "Update extensions now" button doesn't work for them.
Fixed, but apparently not yet released:
http://code.google.com/p/chromium/issues/detail?id=30760#c16