If an extension works for Firebird and/or Thunderbird, then it will have an install.rdf. I think it should also be able to contain a GUID for Seamonkey so that when we load them into the DB, Seamonkey is auto-detected instead of manual. Filing this against UMO cause I dunno where else to put it. Someone please assign this to Ben.

This isn't a UMO bug, this is an enhancement request against browser.

Err. sorry for the bugspam.. I misread. Moving it back to update.

If this is UMO specific, then this is a wontfix. I'm not going to burden Extension/Theme authors with a needless install.rdf just to make adding it to update easiser. I don't see the point in breaking our support of Mozilla 1.x like that.

What is meant by "manual" instead of automatic detection? Does the Extension Author has to specify Seamonkey support, or does someone from UMO has to add the entries to the database? (In reply to comment #3) > If this is UMO specific, then this is a wontfix. I'm not going to burden > Extension/Theme authors with a needless install.rdf just to make adding it to > update easiser. > > I don't see the point in breaking our support of Mozilla 1.x like that. Then why not make it optional? For those that already package their extensions to support Fx,Tb&Seamonkey, it would not be a "burden". And for those extensions that don't have an install.rdf, you could still keep the current scheme.

At the moment, if the extension author does not tell us that it is for Seamonkey, then we do not select Seamonkey from the dropdowns when we add it to the DB. Firefox and Thunderbird are detected from the install.rdf. I don't think it would be a burden on existing FX/TB extensions, just on Wolf for coding it ;-) Ultimately I would like to see non-FX/TB extensions have it just so that it's easier to maintain the database.

The GUID for Mozilla 1.x is 86c18b42-e466-45a9-ae7a-9b95ba6f5640 Now if only I can convince Wolf to add backend support for it.

Back-end support, as long as it's easy enough to code, may be included in the released version of the administration section. but it won't be a requirement, only a feature.

Take a look at the number of Mozilla 1.x only themes and extensions. I don't think this would be a hardship for anyone.

(In reply to comment #8) > Take a look at the number of Mozilla 1.x only themes and extensions. I don't > think this would be a hardship for anyone. Obviously it was a hardship for you, or you wouldn't have filed the bug. so that's not a good defense. :-)

(In reply to comment #9) > Obviously it was a hardship for you, or you wouldn't have filed the bug. I meant a hardship for theme/extension developers.

What's the recommended/allowed minVersion/maxVersion? e.g. is the following good? <em:targetApplication> <Description> <em:id>{86c18b42-e466-45a9-ae7a-9b95ba6f5640}</em:id> <em:minVersion>1.4</em:minVersion> <em:maxVersion>1.8a3</em:maxVersion> </Description> </em:targetApplication>

Please use versions that you have tested with. Since Mozilla doesn't use the new EM code, this is purely for the listing on the website.

First guess: Change if ($mode=="new" and $appname !="Mozilla") { to if ($mode=="new") { as a start.

and take out the if and just use the else if ($appname=="Mozilla") { echo"<INPUT NAME=\"appmozvid\" TYPE=\"hidden\" VALUE=\"$row[vID]\"> <INPUT NAME=\"minappver\" TYPE=\"TEXT\" TITLE=\"Minimum Version* (Required)\" VALUE=\"$minappver\" SIZE=5 MAXLENGTH=6>\n"; echo"&nbsp;-&nbsp;<INPUT NAME=\"maxappver\" TYPE=\"TEXT\" TITLE=\"Maximum Version* (Required)\" VALUE=\"$maxappver\" SIZE=5 MAXLENGTH=6></TD></TR>\n"; } else { echo"$minappver - $maxappver"; }

according to the document Ben wrote isn't 1.8a3 a valid version number. <em:maxVersion>1.8a4</em:maxVersion> so what should I write when my extension works with 1.8a4 ?

(In reply to comment #15) > according to the document Ben wrote isn't 1.8a3 a valid version number. > <em:maxVersion>1.8a4</em:maxVersion> > > so what should I write when my extension works with 1.8a4 ? For Mouse Gestures, I just use 1.8. I'd recommend doing the same, even if your extension *might* break with 1.8 beta or 1.8 final. After all, it only affects the list of extensions visible by default, and only when browser auto detection is left on...

I have changed to this: - can you confirm that the version are right ? - I tested with a CVS version of Firefox 1 week ago ? </em:file> <em:targetApplication> <Description> <em:id>{ec8030f7-c20a-464f-9b0e-13a3a9e97384}</em:id> <em:maxVersion>1.0</em:maxVersion> <em:minVersion>0.8</em:minVersion> </Description> </em:targetApplication> <em:targetApplication> <Description> <em:id>{86c18b42-e466-45a9-ae7a-9b95ba6f5640}</em:id> <em:minVersion>1.7</em:minVersion> <em:maxVersion>1.8</em:maxVersion> </Description> </em:targetApplication> </Description> Thanks by advance. Ps: I will re-upload the XPI this week-end. I can not do it from here.

The same rules apply for this as apply for Firefox with regard to MaxAppVer (I.E. nothing higher than current, as you'll be able to log in and update the value stored in the DB in the future and the client cares not at all). Firefox Version Format does not apply to Suite (at this time). This is an extension of the install.rdf that firefox supports for Update. So a maxVer of 1.8a4 is perfectly legal. :-)

(In reply to comment #17) > <em:id>{ec8030f7-c20a-464f-9b0e-13a3a9e97384}</em:id> > <em:maxVersion>1.0</em:maxVersion> > <em:minVersion>0.8</em:minVersion> You'll need to reduce that maxVer to 0.10

*IF* a install.rdf with a mozilla suite guid is passed, it'll pick up the values, otherwise, it'll present you the drop-boxes as it does now. The fix was entirely too simple too. :-) (unlike Comment #13 and Comment #14 suggested) Look for this in the beta developer control panel which should be landing for testing soon. :-)

(In reply to comment #20) > Look for this in the beta developer control panel > which should be landing for testing soon. :-) I'm glad to hear that - unless it's a closed beta test where I can't participate or need a gmail-like invite :-) Either way, please inform me when I can test something!

Thanks.

Bulk Moving Developer Control Panel bugs to new component. (Filter: massdevcpspam)

Mass-resolving bugs that have been fixed on trunk.

Sorry for the bugspam, reopening bugs wrongly marked as resolved.