There's one feature in my web application which requires a small browser plug-in to work. 99% of the application is ASP.NET + javascript and we have no skills in writing browser plug-ins or any interest in training someone to maintain it so I've used freelancer web sites with great success to get a working firefox plug-in/add-on/extension.
However, the new Firefox rapid release schedule is throwing this whole plan into disarray because every new version of firefox seems to need a new extension. This is not just to do with the em:maxVersion versions in the RDF file; the plugin actually refuses to load, so it seems that every 6 weeks I will have to commission a freelancer to update the plug-in for the next version of Firefox. From my limited understanding this is because each version of gecko is not compatible with the previous one.
I can't help but think I'm missing something here. For instance, the IE plugin was written in about 2005 for IE6 and we have never needed to touch it; it still works with IE9. Is it really the case that all firefox plug-ins have to be rewritten every 6 weeks, or am I doing something wrong?
The basic function of the plug-in is to use a windows timer to poll shared memory and then traverse the DOM to find a page with a specific javascript function which it then calls.
So my question is, is there any way that I can make a firefox plug-in with a more reasonable lifespan (i.e. year or more), or am I stuck with having to release a new one every time a new version of firefox comes out?
The best way to avoid compatibility issues with Firefox addons when using binary code ( c / c++ ) is to use JSCtypes. Here is a recent overview of how this works:
http://blog.mozilla.com/dwitte/2010/03/12/extension-authors-browser-hackers-meet-js-ctypes/
Here is an entry point to the MDN documentation on JSCtypes:
https://developer.mozilla.org/en/js-ctypes
To avoid this long-term problem with compatibility, I would make a port of your C++ code to jsctypes from xpcom a hard requirement for the contractors you are working with.
Related
I am working on a XUL desktop application, where I use the browser tag and load a URL in that tag within the desktop application.
However, some websites display as old format and according to Mozilla, XUL is deprecated and will not be useable at the end of 2017. I want to build the application with the latest technology: WebExtensions.
I have searched many examples on the usage of WebExtensions, but all are working within the browser. Can I make a standalone desktop application just like XUL, but using WebExtensions?
If yes, then please give me some hints on how to get started.
If no, is any alternative for the same requirement available?
Webextensions are fairly limited in their scope. Even if there was an application runtime utilising them, you probably wouldn't get much use out of them due to the restrictive isolation from the host system.
Strictly speaking not webextensions, albeit very similar:
The Electron framework/runtime*
Someone at Mozilla is also working on an alternative dubbed "Positron"** though that software's future is uncertain and there is a chance he might abandon it for an entirely new, highly simplified project (at least that's what I gathered from my conversation with him on Github).
*http://electron.atom.io/
**https://github.com/mozilla/positron
What is the exact difference between plugins, add-on and extensions.
I have read a lot about this and confused,
For example see these four definitions:
1-fire-fox says "Add-ons is the collective name for extensions, themes and plugins" (see https://support.mozilla.org/en-US/questions/790919)
2-www.Differencebetween.net says "Plug-in and Add-on are simply extensions ... Plug-in is the term that is usually used when referring to third party software (interact with a certain program) like flash player ...
3- wikipedia (https://en.wikipedia.org/wiki/Plug-in_%28computing%29) says plugin are being deprecated.
4-I have read in another website that plugins are larger than add-ons and it consist add-on concept.
Also I have read the answer provided in firefox add-on vs. extensions vs. plugins and http://colonelpanic.net/2010/08/browser-plugins-vs-extensions-the-difference/
However I want to understand these differences especially in firebreath where plugins execute automatically through user's consent and add-on should install manually. Also I think plugin embed in htm page while add-on is in form of a separated file like xpi in fire-fox.
Any exact, comprehensive and precise definitions for these three concepts which emerge differences would be appreciated.
General rule of thumb:
Plugins
When you're talking about a web browser, a plugin talks about a NPAPI or similar plugin, which is specific to the page. IE doesn't support "plugins" per se, but they have activex controls which can fill a similar function, though there are also BHO (Browser Helper Object) ActiveX controls which are more similar to extensions. Thus we (the FireBreath team) usually use the term "plugin" to refer to something that works like a NPAPI plugin and the term "extension" to refer to something that works like a typical extension (firefox XPI, Chrome CRX, etc).
Plugins only know about the page they are in; they don't know anything else about the browser or what is loaded in other pages.
Plugins have been responsible for a lot of security problems, since they actually run native code. This has led to a lot of discrimination against them -- much of it deserved. Because of this, and because NPAPI is a royal pain in the neck (hence FireBreath was created), most browsers are trying to phase out plugins. Plugins should never be used unless there is no other way to solve your problem.
That said, there are a lot of cases where they are the only option.
Extensions
An extension is something that is specific to the browser, and they are a bit different on each browser, but tend to be able to learn more about the overall state of the browser; they may be automatically added to pages, accessible separately from a page, etc.
Add-ons
Add-on is more of a generic term which is used to mean a lot of different things. What it actually means just depends on who is talking, but the mozilla definition is probably as good as any; it could be anything that adds functionality to your web browser, regardless of the context.
Key Differences
Extensions tend to be automatic once installed. Plugins are instantiated in one of two ways: 1) by an <object> or <embed> tag in the HTML of a web page, or 2) because they are registered to be the handler for a mimetype which the browser doesn't support.
FireBreath
FireBreath deals with plugins. It has nothing to do with typical browser extensions, only plugins. It is a C++ framework, not a javascript framework, and it allows you to add functionality that can be used from within a web page. Typically FireBreath plugins are used from inside a <object> tag.
FireBreath post-NPAPI
As you may or may not know, Chrome has dropped support for NPAPI plugins (as of version 45) and Firefox has done so as of version 52 (excluding the version 52 Extended Support Release, which will support them for another year). FireBreath 2.0 is now being used in production by several companies and can produce "plugins" (not really plugins, but work similarly) which can work with Google Chrome and Firefox via Native Messaging via a helper extension. The main limitation is drawing; there is no way to draw directly to the browser across native messaging (well, no good way, and no way at all on platforms other than windows).
Eventually we may add support for some abstraction to draw using Canvas / WebGL over the native messaging bridge in FireBreath 2.0, but that hasn't been done yet. Frankly, I don't need it, so I haven't bothered to do it. FireBreath is an open source framework which has unfortunately not received enough support from users in the last couple of years and so the documentation is a bit outdated and there are a lot of little things which haven't been done.
The Native Messaging method relies on an Extension -- we did this primarily to confuse everyone, of course, but also because it was the only way to allow us to communicate with FireBreath plugins from the page in Google Chrome or Firefox.
*(Last updated Mar 6, 2017; Firefox 52 is scheduled to release tomorrow)
Hope that helps. See also:
Browser Plugins vs Extensions -- the difference
FireBreath 2.0 home page
I've just started creating my first firefox add-on and I'm currently in the learning stage, to familiarize with the api.
However I found a little ambiguous what method should I use. After I've read a few tutorials about how to build firefox add-ons using XUL, I realize there's another way:using add-ons sdk which from what I understand is only for firefox 4+ versions only.
I like better the sdk way compared with XUL, however to me the sdk looks like is still in early stage and lacks a few features(I think).
So my question is what road should I take? The new sdk way, which also looks a lot more cleaner than XUL, or to use the good old fashioned way:XUL(of which I'm not a big fan)?
After reading this post: http://blog.mozilla.com/addons/2010/12/09/announcing-add-on-sdk-1-0b1/ I think that the sdk is much better than XUL, however because it lacks a few features like sockets api , I can start my project only using XUL, or postpone it until the sdk will become more mature.
Waiting your thoughts about this problem. Thanks
PS: I'm not interested in developing add-ons for older firefox version(ff3.x)
Add-on SDK is perfect for simple add-ons. Also, it does have access to XPCOM if you need advanced features. So the main issue is UI integration - the options are very limited and nothing comparable to XUL overlays exists.
I recently started using the Dojo firebug extension. I had gotten used to it since it had some nice features (letting you see dojo on the widget level). This was good for me because I am in the process of trying to learn dojo so this really let me see how stuff worked together.
My question is, has anyone found any solutions to get the Dojo firebug extension working in Firefox 6 or should I just try downgrading to FF5?
Thanks
UPDATE:
I tried a workaround I found somewhere else. It said to use the Firefox nightly build add-on, and that add-on would allow me to override the version compatibility. I tried that and it still didn't work.
I recommend trying the Add-on Compatibility Reporter extension from Mozilla. This extension (besides letting you report incompatible add-ons) lets you completely disable version checking.
It's a great way to ensure that older extensions still work when Firefox upgrades the browser every week. Now, this assumes that the issue is with version compatibility, and not that the plugin is actually broken! If it's the latter, there's not much else you can do.
(Also, that's an awesome plugin. I'm definitely going to try it out myself here shortly!)
I am using Ajax / jquery on a webpage i am designing... in order for it to function, i include (at the top of my page) the javascript at: http://code.jquery.com/jquery-1.4.4.js
This works great and all, but i have a fear that
1) the code might get changed without me knowing, then i encounter problems and try to debug for days / hours before finding that the code at this site changed
2) the website is no longer used / specific code no longer hosted years from now
So would it be safer to save that javascript file onto my server, and access it from there?
You should use either a Microsoft or Google CDN. It will be much faster, it will be cached for a lot of your users and it's guaranteed to be there, as opposed to the jQuery link you include.
http://code.jquery.com is jQuery's CDN (provided by Media Temple). The code at http://code.jquery.com/jquery-1.4.4.js will never change; jQuery will release a new version (which will be at a different URL), if anything needs to change (which happens all the time; version 1.5b was released today).
The jQuery guys know what they're doing, and they setup a CDN so people can easily link to jQuery. They're just as (un)likely to bring down the CDN as Google and Microsoft are at bringing theirs down.
See http://docs.jquery.com/Downloading_jQuery for more information.
Having said that, it would seem the Google hosted version (http://ajax.googleapis.com/ajax/libs/jquery/1.4.4/jquery.min.js), is referenced more in websites; this leads to a small performance advantage as far as your users are concerned, as the file has more chance of being cached.
It's safe, notice the version number? As jQuery is updated then that version number will change.
Of course using a CDN will always mean that it's possible for the content delivery network to go out of business. But that's the case with any non directly controlled server.
You of course could use the Google CDN for jQuery, I highly recommend it.
Relevant:
http://code.google.com/apis/libraries/devguide.html#jquery