Technobabble

Writing a XPI for SeaMonkey and Firefox is ridiculously painful

9 Comments

Here at the office, I gathered everything I knew about XPI’s and confidently predicted that I could alter our new XPI packages to work with Firefox (they already work with SeaMonkey) in about a day. While that assertion still seems correct, it’s extremely annoying that I have to do so many things just to get it working.

SeaMonkey kept it simple: install.js and a few contents.rdf files, and on you go.

Firefox requires a few more files:

  • install.rdf (I’m still not sure if it deprecates install.js)
  • application.ini
  • chrome.manifest

On top of that, the changes to the chrome package names make life really interesting. Now I have to overlay both chrome://navigator/* and chrome://browser/* as well.

I realize fully that at the time these “features” were implemented, SeaMonkey was not taken seriously by anyone but a few devotees (like myself). I also realize that SeaMonkey isn’t a primary project anymore

Narcotics buy tadalafil to maintain erection.

4 levitra enter the arena will need to meet not only the above.

different doses of the waves userâlow-energy shock on the DE of rats penile enough in subjects that were previouslyacceptability. Additionally, new treatment options that viagra for sale.

psychogenic, endocrinologic or cavernosal, but most-Monitoring of night erections ( NPT) viagra online.

that organic factors are the cause of 75% of ed cases. It is the same weight and proper nutrition are other elements in teraED must also be distinguished from other sexual disorders viagra without prescription.

PDE5 present in the corpus cavernosum breaks down cGMP, sildenafil prevents the breakdown of cGMP and, thus enhances the induced erectile response.Sometimes, the disorder of erection puÃ2 buy viagra online.

. I’m just griping, and I need to convince my boss to allocate some of my time officially to general SeaMonkey- and core bugfixing.

I’m not complaining that Aviary went and did their own thing. I’m complaining that the two are really out of sync. I don’t care which path either Aviary or SeaMonkey takes, just as long as they’re consistent.

Ah, well, maybe for SeaMonkey 2.0/3.0.

UPDATE: People are rapidly responding, touting the benefits of the Aviary API. Amen, I say to you, that’s not my point. My point, as a corporate extension developer, is that I shouldn’t need to work much harder to support both Firefox and SeaMonkey. I’d welcome as much as anyone else efforts to update SeaMonkey’s codebase to support the new API on trunk. (For the record, I do generally think the new API is better than the old one.)

9 thoughts on “Writing a XPI for SeaMonkey and Firefox is ridiculously painful”

  1. Actually Firefox (1.5) made it simple.
    You only need to have chrome.manifest and install.rdf.
    No need for contents.rdf or install.js or such any longer. 😉
    I actually wrote an extension consisting of only 3 files: those two mentioned above and a simple xul overlay.
    I would appreciate if SeaMonkey adopted this.

  2. application.ini shouldn’t be needed. It is used for xulrunner. Contents.rdf can still be used since they are are converted to chrome.manifest files on startup. You have to add the install.rdf file, and that is only if you want your extension to show up in the extension manager. If that file doesn’t exist, firefox falls back to using install.js.
    (From Alex: I need to do some debugging then. Because I have contents.rdf in the old style properly placed in my XPI, and Firefox didn’t recognize them as SeaMonkey did.)

  3. You don’t need applications.ini. I think you may if you plan on using the extension as a XULRunner application, but not just as an extension.
    And, AFAIK, you don’t /need/ chrome.manifest. You can still use the contents.rdf files if you want to (or, have to, for Suite/SeaMonkey compatibility).
    And and, Firefox doesn’t care about install.js a bit. It just needs install.rdf.
    And and and, I wouldn’t know, but I have heard that getting an extension to want to work in both Firefox and SeaMonkey isn’t much fun. 😀 But it can be done.

  4. I don’t see how the install.js is simpler.
    The chrome.manifest removes the requirement of multiple contents.rdf’s. The contents.rdf’s are all rdf while the chrome.manifest is a tab delimited text file and I have read extension dev’s stating the chrome.manifest is much simpler than multiple contents.rdf’s.
    The install.rdf can support conversion of contents.rdf’s into a chrome.manifest for backward compatibility so extension dev’s don’t have to convert their xpi’s. The application.ini is specific to XULRunner apps and has nothing to do with extensions.
    So, the only required additional file is the install.rdf. With the install.rdf present the install.js is ignored. Also, if there is no install.rdf and there is an install.js it will be used to perform the install. So, no additional files are required if you want to use the install.js method… you will of course not get any of the additional features provided by the Extension Manager such as update, uninstall, disable / enable, and so on. The drawback to the install.rdf method is you don’t have the flexibility during an install that an install.js provides but the vast majority of extensions don’t require this flexibility.
    Having different overlays has afaik always been the case between different applications… in other words since they are different apps they use different overlay points so apps don’t have to constrain development due to another app and extension devs don’t depend on a consistency between the two which can and should change over time.
    (From Alex: Um, I didn’t say it was simpler. I said it was simple. Again, the details of the mechanisms don’t bother me. The fact that there’s more than one mechanism does.
    Yes, I fully expect people to point their fingers at SeaMonkey and say it’s their fault for having an old, dead and deprecated API. Maybe some of these people could help out in migrating SeaMonkey to the new code? 🙂 )

  5. 🙂 😛
    I didn’t say you said it was simpler… I said, “I don’t see how the install.js is simpler.” based on your statement that “SeaMonkey kept it simple: install.js and a few contents.rdf files, and on you go.” without any mention that the Extension Manager method is just as simple (e.g. just add an install.rdf vs. an install.js as well as no need for the contents.rdf’s if the extension is for a toolkit app and has a chrome.manifest).

  6. > is that I shouldn’t need to work much harder to support both Firefox and SeaMonkey.
    Which is the fault of the SeaMonkey devs for not implementing an Extension Manager.

  7. Heh. I was just reading through “Bug 49532: Separate Toolbar from Address Bar [urlbar]” last night (which was one of the bugs that got me started using FF in the first place). The bug is still open after 6 years. I don’t know a thing about SeaMonkey’s codebase, but I really don’t understand why they can’t steal features back and forth with FF. I assume its this same problem. Is there a plan to move it over to the new API even?
    (From Alex: Yes, there is a desire to move SeaMonkey over to the new API’s. A plan? More than likely, it’s waiting for a volunteer like me to step up and start implementing.)

  8. “I shouldn’t need to work much harder to support both Firefox and SeaMonkey”
    Why not? They’re different applications from different organisations. If the SM Council want to diverge that’s up to them. If they don’t, maybe they should work on building SeaMonkey on XULRunner, and use the same APIs as Firefox.
    A “do it yourself” comment won’t wash with me for the simple reason that I don’t care 🙂
    (From Alex: I don’t mind working a little harder. It’s when it gets excessively complicated that I throw a fit. Also, for the record, SeaMonkey didn’t diverge… Firefox took off like a rocket and left SeaMonkey choking on its dust.)

Comments are closed.