I recently wrote How to develop a Firefox extension. It’s an overview of the different ways to create add-ons for Firefox and Firefox for Android. It points to the documentation you need to get started but it doesn’t get into specific technical matters.
If there’s any particular development topic you would like us to get into in a blog post, let us know!
A tutorial for the developer extension is possible?
There are a couple of extension development tutorials on MDN. Most are out of date, but the ones for SDK add-ons should still be valid. If you can contribute a new tutorial, that’d be great 
i want learn how to create developer extensionm 've read the MDN documentation but i’ve see JPM and new tools for the extensions development. So i don’t know if better write extension with the actual method or the new not official.
I’d recommend using the SDK in the way it currently works. You should be able to move to JPM and the new tools easily once they are part of a release version of Firefox.
Uhm i’ve see that the only way for create a Firefox developer tools addons is use https://github.com/victorporof/Restartless-Template .
There is other documentation? On MDN i’ve founded only the documentation for create a extension development environment.
Yeah, if you’re trying to extend the developer tools, that’s probably your best bet. There might be some more info on blog posts and the Developer Tools docs.
HI am a newbie in addon development and am looking forward for solutions to some of the major problems i am facing in addon development using sdk . I have tried the stackoverflow ,mailing list and the irc channels too but am disappointed by the response received . would be great if someone could help me out with the following questions.
My first post. I need to see aome motivation for taking part in this forum. Where is the description of the benefits of bothering with Add Ons of any sort. I’m intrigued but unconvinced I should spend time using any Add on. In short, I want to know in crisp language - What is the point of add ons
I thinks this point has been overlooked because those involved can’t see the wood for the trees/
This doc might help you understand the motivation:
https://developer.mozilla.org/en-US/Add-ons/Why_develop_add-ons_for_Firefox
There’s more information on MDN.
Sir will you explain how to make a plugin for firefox greater version and related sdk. My plugin is working for mozila 3.6 version and i want to upgread mozilla to greater version like 37 . i created component.dll using 1.7 xulerner sdk how can i upgrad it.???
Binary XPCOM components are no longer supported in Firefox. There are some alternatives pointed out in that article. There’s more information about add-on development here.
I’ve made my first simple add-on. What would be the best spot to start to learn how to add options to my add-on? Options, as in, an options menu for a user to turn on or off certain elements.
If you’re using the Add-ons SDK, this is what you want. For other add-ons you’ll have to create a custom prefwindow and link it from the install manifest.
@jorgev, you write some very helpful blog posts, however, I have one major criticism. Not just directed at you, but at Mozilla in general (I just happen to be looking in this addons area mostly).
Please stop writing documentation in blog posts and forums! Put them in, well, standardized documentation and reference manuals. You know, with a menu and categories that are quick and intuitive to get what you want. Or at the very least, blog about it for feedback, then commit them to standardized documentation and update the blog with a link at the top to refer new people who found it by search engine over to the documentation area. The DOM and JavaScript documentation is looking pretty decent. But the “meta” information, about how to set up an addon development environment, etc, needs improvement. You have great information, and write it well, it just has a barrier to accessibility!
It is truly maddening to have to search extensively around multiple, disparate Mozilla-run documentation sites, blogs, and now a discourse (a forum by any other name…) too, and all of this utter nonsense, just to find helpful information on basic topics. This is more than anything the biggest barrier to access of information about and development of addons. The amount of time spent trying to find documentation is excessive.
As an example, with the new requirement as of version 43+ that all addons must be signed to run (46+ without the config option to override), nowhere in the developer targeted article does it address what developers are supposed to do? Submit for signing for each and every change during the development process? Is it required to use a beta version only of the browser? How to test compatibility with the current release and a the past year or two’s version if it can’t be run? Oh, right, the answer was buried in some blog post somewhere. At least they included a link to it. We can temporarily disable the disabling of unsigned addons, per addon. But only for restartless addons? Which means all overlay addons are instantly obsoleted? Or what? Oh, your blog was written about 2 years ago, before the policy change for mandatory signing. This is an example of the reason DOCUMENTATION DOES NOT BELONG IN BLOGS!
These are all CRITICAL to writing an addon as of 46+, and ought to be covered in your otherwise great primer.
Example of URLs referred to above.
How to develop a Firefox extension
Legacy Extensions (which should address signing issues and jpm and SDK requirement)
Signing and distributing your add-on
Add-on signing in Firefox
Add-on Signing Update
Signing Firefox add-ons with jpm sign
jpm
Thanks for the detailed feedback. However, most of the things you mention are documented on MDN, and you even link to some of them. The information that needs to be permanently available should be on MDN, I agree. I also agree that our documentation is fairly difficult to navigate, particularly for add-on development.
One of the benefits of having a well-defined API like WebExtensions is that it can be more easily documented. We will phase out the documentation for overlay and SDK add-ons as those become less important (this will take a couple of years), and the WebExtensions docs will hopefully be better organized.
We won’t stop blogging about these things, however. There are people who follow our posts but don’t read MDN regularly. Same goes with this forum, IRC, lists, etc. We have a very diverse audience with different entry points and preferences, and redundancy does more good than harm IMO.
Have you any specific data to backup your decision to blog documentation versus documenting documentation? Polls? Research studies? Feedback from users that say “yes, I love to jump all over blogs rather than look in a manual”. Is this anything other than a unilateral decision, or a new “trendy” tradition, or Mozilla-internal cultural phenomenon?
What I am hearing are irrational justification (excuses). While it is acknowledged that standardized documentation (when it is of the detail and quality of which you guys are absolutely capable), is easier to access for most people, the decision is to continue to make things difficult for the majority, rather than inconvenience a few people who like to be inefficient and disorganized. No, we will not stop blogging our documentation, hurrah! But maybe we will add some of that info to MDN from our blogs, but oh wait, that would be too much work, boo, hiss!
Yet more excellent reasons to adopt just about any other browser platform than Mozilla. It’s like Mozilla is actively trying to drive away developers. You guys are really not not listening to, hearing, or heeding the feedback of the addon developers. The only reason that users still use this browser platform is for addons, so your strategy, drive away all the addon developers by adopting the most insane environment possible. Have you ever read this article? Writing Extensions for Firefox Is Barely Worth the Trouble This article is 2 years old, yet my experience with the documentation is just as relevant, which means you guys are still not getting the message.
I have used Mozilla since it was spelled M O S A I C, probably as long as some devs have been alive. I used Netscape on UNIX before they had a Windows version. I used to love the documentation (when the first things worth documenting came into being, like JavaScript docs in a downloadable zip file). It made doing things very easy because it made LEARNING very easy. Other software projects that have been widely embraced by developers typically have had easy access to quality documentation. PHP is a shining example. I want nothing more than to continue to support the project, out of a fanatical sense of loyalty and tradition. But even I have my limits, and I am rapidly approaching them.
However, I am here to honor my choice to help out someone with an addon, and to learn more about the process (for better or worse). So I will just have to shrug. These are my takeaways. Mozilla is unreliable and uninterested in the quality of the addon developer experience when it comes to documentation and long term support and viability of the project, and gleefully and proudly jeopardizes the future in exchange for rock-star blogger status. In many regards, Mozilla suffers from a complete and utter failure with addon developer relations.
Sorry if I sound harsh, but it is born out of a frustration of a long-standing problem not being addressed and proactively ignored. As a person in a position of addon relations leadership, we rely on you to take feedback, and advocate for change within the organization, rather than dictate policy based on flimsy rationale and blatantly ignore criticism. I respect the work and contributions here at Mozilla by so many staff and volunteers.
As just some random peon, what can I possibly do to address this problem more proactively? Does the doc team need some grunt to wade through blogs and collate results? Maybe develop some semi-automated tools which can detect blogs of high interest, to help optimize the process of capturing this valuable information into documentation? If I have experienced anything with Mozilla as a casual observer over the years, it has been an overwhelming tendency that each group becomes more and more entrenched in unproductive and unhelpful practices, and less willing to cooperate with one another (many kings of many hills), which discourages people from wanting to contribute, because who needs the aggravation of fighting an uphill battle against an organizational culture of dysfunction.
I have not got the experience to affirm or deny the above claims but I have found trying to find help in writing an addon extremely difficult. My biggest problem is that I am developing an addon that my company needs for Thunderbird and you’d almost think that Thunderbird doesn’t exist. Everything is about Firefox and there are NO examples of Thunderbird addons.
My big questions are - 1. when will XUL be depreciated for Thunderbird?
2. When will addons for Thunderbird need to be signed.
Blogs may be annoying but there are very few of even those in Thunderbird specific areas. I don’t know how developers of Thunderbird addons find information.
Of course, if XUL won’t be depreciated for Thunderbird, can you please maintain (and update) any tutorials that talk about it for new developers. Or is that a question for the team? developing Thunderbird? Or will all this go the way of Eudora?
Blessings
That’s accurate. The level of support Mozilla gives Thunderbird has varied along the years and traditionally hasn’t been great. All add-on documentation and support is handled by a small group of contributors who work really hard on keeping the project alive. I don’t expect this situation to improve in the future, to be frank.
For Firefox, XUL extensions are planned to be dropped by the end of 2017, and dropping XUL entirely is just a proposal that could take years to complete. For Thunderbird such changes might never happen. To drop XUL extensions there would need to be support for the new API (WebExtensions) in Thunderbird, and I know of no plans to do this.
As far as I know, extension signing won’t be a requirement for Thunderbird.
I suggest you give the Thunderbird planning list a look. You may find the answers to your other questions, or get answers directly from the people in charge.
I would love to see a lot more detail about initial development and “signing lifecycle” for developing an add-on.
I am new to add-on development, and as far as I can tell, I have to get an add-on signed even if I just want to run/test locally. Is that correct?
I had node installed, and installed JPM. Did a JPM INIT and created a shell/empty extension. Great so far…
I execute JPM RUN and it says my empty extension is disabled and not verified. Same with JPM TEST. Click on the link and it discusses signing…
So, I look at JPM SIGN. Eventually figure out that I need to go get tokens. Get those and JPM SIGN fails: figure out there’s an annoying issue with timezone and Windows in signing. Work around that and get my XPI file…
Execute JPM RUN again and I still get the disabled and could not be verified. However, if I open the XPI file directly, it works…
What am I doing wrong? For every time I want to effectively build my extension, do I need to get it signed?
Where is a walkthrough?