Mano is trying to upload an update to his extension moving BiDi Mail UI from 0.7.2 to 0.7.4. The update requires two uploads. One file is for Thunderbird, and one file is for SeaMonkey. On the second upload, he gets the identical version error, even though the .xpi itself is different and it is for a different product. In the past, the behavior was that they would be allowed to release multiple .xpi's per version and per product because they were allowed to submit over the top and replace existing versions (until we fixed bug 287977). Question is -- what do we do for Mano? He wants to submit an updated .xpi for 0.7.4 that is compatible with SM. * Update additem.php to allow this behavior * Work with him to find a way to create a universal .xpi (if possible) * Create a new add-on (same info, just "BiDi Mail UI for SeaMonkey")

To make update work, creating a new item is probably not a good option, since we'll need to keep the UUID the same. A universal XPI is probably the right path here, and we should make sure that we work to fix this more generally in Remora. If a universal XPI isn't viable, we could probably do some one-off manual thing with an upload and a SQL ticket.

Note this is a regression, I had no such issue when uploading previous versions (see BDM 0.7.2 for example).

Universal XPI is not really an option on my side fwiw.

Yeah, it was caused by 287977 per morgamic.

AMO has not previously supported multiple files for different products, only for different platforms. The additem script has *allowed* the upload of such files prior to bug 347822 being fixed, but the public side has never served such files with logic - only the most recently added. Extension developers have previously assumed that this feature was available and uploaded separate files for different products, but it has never been supported. For an example of this, see https://addons.mozilla.org/firefox/60. The install button will always point to the fx+fl version of the file even though there is a mz file available. You can visit that url in Mozilla or change https://addons.mozilla.org/mozilla/60 and you'll still get the Firefox/Flock file. This would certainly be helpful to some developers, but it is not a regression and the Remora team has decided that it will not be a feature supported at launch.

Experiencing the same problem with my removedupes extension (removedupes.mozdev.org). For me also, a universal XPI is not an option unless I can have per-app (and preferably per-app-version-range) manifests with file renaming/aliasing.

You can have per-app overlays in chrome.manifest. For ex: # Firefox overlay chrome://browser/content/browser.xul chrome://weatherfoxie/content/overlay-fx.xul application={ec8030f7-c20a-464f-9b0e-13a3a9e97384} # Thunderbird overlay chrome://messenger/content/messenger.xul chrome://weatherfoxie/content/overlay-tb-sb.xul application={3550f703-e582-4d05-9a08-453d09bdfdc6} # Sunbird overlay chrome://calendar/content/calendar.xul chrome://weatherfoxie/content/overlay-tb-sb.xul application={718e30fb-e89b-41dd-9da7-e25a45638b28}

Thanks for filing this. In an effort to not drown in existing reports we're aggressively closing old enhancements and bugs to get the buglist to a reasonable level so we can scope and process bug sprints in an effective manner. Patches for this bug are still welcome.

(In reply to Wil Clouser [:clouserw] from comment #9) Although I'm not the original reporter, I must say your comment, Wil, is offensive. This is an outstanding issue; you don't get to "not drown" in it by deleting it. Also, a WONTFIX means you have made the decision it is better to leave this bug unresolved than to resolve it, which requires at least some justification. Finally, your closing deletion of the bug and your praise for filing it are relatively controversial. I strongly suggest this bug be reopened - and fixed.

It's not meant to be offensive. This bug is the lowest priority bug we have (P5) and is approaching 8 years old. There are currently no active developers on AMO and there haven't been for 2 years. Realistically, with our current resources, this bug won't ever be fixed. If someone gets some time and wants to fix a bug I currently point them at a bug list of 1250 bugs. They start reading, their eyes glaze over and they leave. If I can see a list of 100 prioritized bugs I can help direct them to one that would be useful. With a smaller list of bugs I may even be able to scope a few releases and get some developer time from other projects.

(In reply to Wil Clouser [:clouserw] from comment #11) About the priority - this is circular reasoning. The priority should be higher; closing due to low priority is closing because you (= collective you) decided it's close-worthy. Regarding the lack of current developers on AMO - I would have tended to accept this several years ago. But these days, Mozilla is a corporation, and to the best of my knowledge it's bankrolled by Google. Not as much as it should be, but instead of closing bugs, we should be signing petitions addressed to Mitchel Baker or something. And, again, even given everything you wrote - the bug should not be closed. Take heart and learn to live with having many unresolved bugs. I know I have (with my extension)... So, again, suggest a reopen. As for the priority, it's quite possible many other things are more urgent.