0

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.

Wladimir Palant
  • 56,865
  • 12
  • 98
  • 126
Jonathan Henson
  • 8,076
  • 3
  • 28
  • 52
  • 2
    Are you asking about NPAPI plugins or XPCOM components in Firefox extensions? The documentation talks about the latter, you seem to be worrying about the former... – Wladimir Palant Aug 18 '12 at 00:42
  • @WladimirPalant NPAPI, I thought that Gecko SDK was the SDK for NPAPI plugins. – Jonathan Henson Aug 18 '12 at 19:16
  • 1
    Nope, the SDK is primarily used to compile XPCOM components for Firefox extensions and the like, the documentation seems to make the assumption that it used for that goal exclusively. NPAPI plugins however definitely can be compiled with older SDK versions and will continue to work (otherwise Flash would stop working on each Firefox update). – Wladimir Palant Aug 18 '12 at 20:13
  • @WladimirPalant That is why I seriously doubted that what I was reading was true w.r.t NPAPI plugins. Anyhow, can you kindly point me to the correct SDK? Also, can you just answer with all of these comments so I can vote you up, accept, and close out the question? – Jonathan Henson Aug 18 '12 at 22:06

1 Answers1

2

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).

Community
  • 1
  • 1
Wladimir Palant
  • 56,865
  • 12
  • 98
  • 126
  • Also if you haven't you should take a look at FireBreath (firebreath.org) before you dig too far into NPAPI; it abstracts a lot of the issues you'll have to deal with in plugins as well as making plugins work on both IE and NPAPI-compatible. Even if you decide not to use FireBreath, the FireBreath community is probably the best resource for figuring out the NPAPI – taxilian Aug 19 '12 at 23:02