Firefox & Thunderbird Add-on Converter for SeaMonkey

[Philip Chee]

Converter update: Progre works in SeaMonkey!

WoW! I didn't expect that to work in SeaMonkey. You absolutely rock.

Phil

[Lemon Juice]

Actually, Progre worked almost "out of the box" with SM, the only problem was that it made the location bar unusable for keyboard by throwing js errors. So the key was to get rid of the errors, which were also a bit unusual for a typical extension. But I was also surprised that the code doing the main thing in the location bar just worked.

[patrickjdempsey]

Cool! That looks like something I need to test against SeaFox.

[Lemon Juice]

Well, it still has a small glitch in SM because it causes the "Paste & Go" context menu item not to show up, I still haven't figured out how to bring it back. This extension is quite invasive in overwriting a bunch of native location bar XUL code but it's still surprising that in spite of throwing so much of Fx-like stuff in that place it still works.

[patrickjdempsey]

Sounds like it's going for overkill. You shouldn't have to replicate the entire urlbar binding stuff to add a progress bar.

[LoudNoise]

Toshio 'ADAM' Kudo has an interesting collection of extensions. It might be a case of solving a personal problem and then releasing it to world. It might not be the best way but he/she can maintain it.

[hawk-lord]

I converted Simple Currency Converter 1.0.15 and it works after two additional changes in the source code. I have to go via Add-ons Manager to get its settings menu but I haven't checked why yet.

It would be a good idea to write in the conversion form that "2.*" is not an accepted version number and add a link to the page with real version numbers (currently up to 2.34 for SeaMonkey).

[patrickjdempsey]

For version numbers, unless you are uploading an extension to AMO, you can use as high a number as you want. For at-home projects a version range like this will keep you running for a long long time (until a change in SM actually REQUIRES an extension update):

<em:minVersion>2.0</em:minVersion>
<em:maxVersion>3.0.*</em:maxVersion>

[tonymec]

For version numbers, unless you are uploading an extension to AMO, you can use as high a number as you want. For at-home projects a version range like this will keep you running for a long long time (until a change in SM actually REQUIRES an extension update):

<em:minVersion>2.0</em:minVersion>
<em:maxVersion>3.0.*</em:maxVersion>

OTOH, you might not want to set TOO high a maxVersion, especially now that Firefox, Thunderbird and SeaMonkey have a default-to-compatible feature.

So:

• 2.33.* is "safe" since 2.33a1 can already be tested (except on Windows)
• 2.37.* is a wager on what there will be in about 6 months
• I wouldn't set even 3.* since at the present pace, there would need extremely large changes before the SeaMonkey Council would decide that a change of major version is warranted.

Just my 0.02 € of course.

[Lemon Juice]

It would be a good idea to write in the conversion form that "2.*" is not an accepted version number and add a link to the page with real version numbers (currently up to 2.34 for SeaMonkey).

Why is 2.* not an accepted version number? Most of the converted addons should be treated as experimental anyway, so there's no reason to limit maxVersion since we accept that compatibility may stop at any future SM release. For people who have any reasons to have a different maxVersion they can enter it manually into the field.

[patrickjdempsey]

OTOH, you might not want to set TOO high a maxVersion, especially now that Firefox, Thunderbird and SeaMonkey have a default-to-compatible feature.

Honestly, the rules about when that works and when it doesn't work is so darned confusing I don't think it's worth worring about. And I believe it doesn't work on first install from a local source. It only works when installing from AMO because they automatically do version-bumps.

Eventually *all* extensions break, I just think it's making things more difficult than they have to be to get overly specific about a local install.

[tonymec]

It would be a good idea to write in the conversion form that "2.*" is not an accepted version number and add a link to the page with real version numbers (currently up to 2.34 for SeaMonkey).

Why is 2.* not an accepted version number? Most of the converted addons should be treated as experimental anyway, so there's no reason to limit maxVersion since we accept that compatibility may stop at any future SM release. For people who have any reasons to have a different maxVersion they can enter it manually into the field.

AMO won't accept that because it is “too far ahead” in the future (by their criteria).

2.34a1 is out since today; 2.34a2 will be in 6 weeks; 2.34 beta, in 3 months, will pretend that it is a release or pre-release (and have just "2.34" in its UA string); the final 2.34 release is expected in 4½ months. AMO already allows all three of these versions (2.34a1, 2.34a2 and 2.34), two of which are in the future. Nothing farther out. Same thing for Firefox & Thunderbird, whose first 37.0a1 nightlies have come out today or yesterday, and for which AMO allows maxVersion strings up to 37.0a1, 37.0a2 and 37.0 but nothing further up.

If your extension is a "generalized Toolkit extension" which supports all three of them, and probably any Toolkit application, then you may perhaps circumvent this limitation by adding a targetApplication section for toolkit@mozilla.org, which is accepted by any Toolkit application but (I've been told) isn't checked by AMO. But if you do that, you should make the maxVersion "strict", and if necessary bring it down, if it is found that an incompatible change has been made at some version in any of the Toolkit apps.

[Lemon Juice]

AMO won't accept that because it is “too far ahead” in the future (by their criteria).

Yes, but the addon converter is not meant to create extensions for submitting to AMO but for installing them and using locally. Therefore, it doesn't matter it's too far ahead in the future, what matters is that the extension doesn't stop working in the future because of too low maxVersion.

[patrickjdempsey]

No, 2.* is not accepted because it is not a valid version format. It has nothing to do with it being "too far". These are the only formats they accept for versions:

X.yy

X.yya1

X.yya2

X.yy.*

At any given time, AMO will only allow you to upload a version with a maximum "yy" of the current Nightly. However for local installs you can use whatever version you want.

[Frank Lion]

AMO won't accept that bec

There's your mistake in the first line. AMO doesn't come into this at all, you are answering a question that was never asked.

Even if it had been the question, the polite answer was just to link to here - https://addons.mozilla.org/en-US/firefo ... pversions/ which is constantly updated.

Now, please, give it a rest.