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.???
Sorry my post was under the wrong topic. It was my first post and I didn’t understand everything so I edited it and re-posted it under “Proposals for New Add-ons” which was a suggested topic for my post.
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.
@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).
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
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.
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?
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?
There isn’t a walkthrough for JPM, but you can use this method to test your restartless add-ons in Firefox. Even better, you can also move to the WebExtensions API.
There are other ways to run unsigned add-ons, which are listed on this page. I don’t know if there’s a way to make
jpm run work with them.
Thank you Jorgev; I will investigate those options. As side notes:
I’m creating a side-bar add-on, so I’m pretty sure I can’t use the WebExtensions API, at least yet (please let me know if I’m wrong).
I’ve tried some of the techniques such as setting xpinstall.signatures.required to false, but since I’m using 48, I don’t think that specific technique will work.
That’s correct. There’s a bug filed for it, but no real progress so far.
You would need to use the unbranded builds, also explained in the wiki. It’s best/easiest to do your testing in Developer Edition, though.
Thanks for the post. I am looking for a good tutorial on reading input from HTML panel, store and retrieve the input. e.g. user entered list in the script. What are the possible ways to do this?
I joined the tb-mailing list but that seems to have died now and maildev digest has taken it’s place but there seems to be no more help for tb developers. I read just recently that legacy non bootstrapped extensions are not to be supported so I looked around and there is NO help that I can see that is accessible to upgrade a legacy non bootstrapped extension to a restartless one. I would really love to see one basic example of each type… one on changing the main display and one on changing the messaging display. I looked through a stack of addons and MOST are not restartless. It seems that addons are really not supported any more.
A post was split to a new topic: Allow an extension to configure Firefox security devices