What are the minimum programming requirements to create a Firefox plugin?
You need to learn XUL for the UI and Javascript for the programming.
more infos here:
https://developer.mozilla.org/En/Developing_add-ons
Firefox plugins (such as things like Flash player) are binary components you develop in NPAPI the cross-browser API for plugins.
Check out Mozilla Plugin Developer Center
You might also look into Firefox Extensions sometimes Firefox plugins are shipped as extensions. Firefox extensions modify or enhance the functionality of the browser itself. Javascript is primarily the language you'll be writing a Firefox plugin.
Check out the Mozilla Extensions Developer Center
Some Firefox plugins that come in handy when developing Firefox plugins are the Venkman Javascript Debugger and Firebug Javascript debugger
If you are into an organized style of reading, and prefer an good ol' book, start here.
http://www.amazon.com/Programming-Firefox-Building-Internet-Applications/dp/0596102437
It will get you started on the basics on XUL, which is in turn used to build the addons. If you have a touch in javascript, it will definitely help you.
Else,
Start here.
https://developer.mozilla.org/En
You can start learning what all you will need to start developing firefox addons, or even firefox itself.
If you are fairly proficient in Javascript and DOM, then, just jump here.
https://developer.mozilla.org/En/Developing_add-ons.
The only problem might be, they are as not comprehensive for a newbie programmer. If you have some professional background in programming, and can pick up a language from sample codes, then start here.
But I would definitely suggest a well organized book, like I mentioned above. There are very few XUL book in the market, this was my first google result, so just linked it here.
Search for XUL on http://www.amazon.com/.Choose one, atleast a book published after 2006-07.
[edit]
Just found out this good article
http://kb.mozillazine.org/Getting_started_with_extension_development
There seems to be a huge misunderstanding here; Are you trying to create a plugin or an extension? As Dougnukem stated, plugins have nothing to do with XUL or extensions. They are shared libraries (.dll, .so, or .dylib for win, linux, mac) that provide functionality that the browser isn't capable of alone.
If you're just getting started, I'd recommend looking at the FireBreath plugin framework and reading through some documentation. A decent place to start is: http://colonelpanic.net/2009/03/building-a-firefox-plugin-part-one/
Also, you still haven't selected an answer for this question; is that because you haven't found an answer yet, or because you've forgotten?
Advanced DOM, the Firefox API
Related
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 would like to define different actions for different pages
I would like to do like this, when I entry :
wwww.test.com/page1.html : alert Hello!
wwww.test.com/page2.html : alert Good morning!
wwww.test.com/page3.html : alert Hi!
How do I implement this idea
Any tutorial links? thinks so much!
There are three general types of Firefox add-ons: Overlay, Restartles (Bootstraped), and using the Add-on SDK (Software Development Kit). There is a good article comparing the three types on MDN (Mozilla Developer Network).
In general, the most flexible are Overlay extensions. Bootstrapped (Restartless) extensions sacrifice some of the capabilities available to overlay extensions for the ability to install and uninstall without requiring the user to restart Firefox. Add-on SDK extensions sacrifice a considerable amount of the capabilities available to the other two types of extensions for having an abstraction layer between the extension writer and the guts of Firefox. The Add-on SDK is intended to make writing extensions easier and reduce the amount of work needed by the person writing the extension to maintain compatibility with future versions of Firefox. It mostly succeeds at this, but it does fail in some ways.
There are tutorials available on MDN:
Getting Started with Firefox Extensions
XUL School Tutorial
Building an extension
Add-on SDK Tutorials (many)
Many more
MDN is a good resource for information about extensions. When working on Firefox extensions I typically have at least one tab open to a Google search for "MDN " and then whatever I am looking for. It is my go-to method of finding documentation for developing Firefox extensions.
There are a couple of forums which have good information:
Mozilla Add-on Forum (Official)
mozillaZine
Welcome to developing extensions for Firefox.
As to the specific question you asked, the exact code depends on if you are using the Add-on SDK, or not. For the SDK, you should read Working with Events and Listen for Page Load among others. For the other types: Intercepting Page Loads, Listening to events in Firefox extensions, and On page load (Code snippet); also among others.
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.
If you were going to start developing a new Firefox add-on today, would you still use XUL/JS or would you start using Jetpack, the new add-on framework?
The XUL way of creating add-ons will continue to exist on Firefox 4 but Jetpack is clearly building steam and I imagine it will become the only way of creating add-ons in the future.
Is it already the time to start looking to switch/migrate to Jetpack?
JetPack and XUL are not mutually exclusive. JetPack is a set of APIs that you can ship with an add-on that are tested by Mozilla and guaranteed to work. I'd suggest you start with JetPack, and if you need to do something more powerful, you can start adding XUL and other JS files to accomplish what you need. JetPack is designed to be simpler, but you can also step into the scarier world of extension development without issue.
I don't know yet Jetpack, but I coded a large extension for Firefox two years ago using XUL and it was really, really painfull.
I think Jetpack has to be better and simplier, and it's worth it to give it a try.
It depends on the size and scope of your add-on. If you believe it to be fairly simple, than I would start with XUL and only switch to the framework when you hit walls and find yourself saying "there must be a better way!"
I haven't used Jetpack, but I do agree with others here that XUL isn't always pleasant. It's amazing how often the documentation is missing some obviously key piece of information. Jetpack may smooth that over for you. Alternatively, you could help improve the documentation. :)
I want to develop Safari plugin using xCode, What API should I use? Someone can give me some documents or sample codes ,Thanks very much!
The answer is rather complicated i'm afraid.
Unfortunately, Safari the web browser does not have a plugin API. That means you technically cannot extend Safari's user interface or features using plugins.
However, WebKit the web rendering engine (which powers Safari and many other browsers/apps) does have a plugin API (actually it has 2) which allows you to create plugins for rendering web content inside webkit webviews.
You can find documentation on developing WebKit plugins in Apple's docs here. (PDF Link!)
Also note: Safari's lack of a true plugin API has not stopped lots of developers from developing various pieces of software which they call "Safari plugins" even tho they are technically not Safari plugins. They are usually something called an "Input Manager" which are widely viewed as rather questionable pieces of software. Input Managers always seem to be on the cusp of becoming unsupported or broken by Apple. It's not really clear whether Input Managers are kosher with Apple or not.
Then again, several "Safari plugin" Input Managers are quite popular, so....
Input Managers are a whole other topic. I'm sure if you google it you can find a lot of information on them. However, personally I would advise against developing an Input Manager due to their questionable status in the Mac software world and their constant danger of becoming unsupported or badly broken.
Update: A few years after I originally answered this question, Apple did provide a sort of plug-in API for the Safari browser itself. However, they are called "Extensions", not plug-ins.
See the Apple Safari Extension Programming Guide for details.
Check out Rentzsch's ClickToFlash, it's a plug-in that is fairly well documented, along with neat source code.