Bugzilla

Thanks for the review, Magnus!

> Looks like you'd run into this for the IM account case? For that, unique and accountIds would be different size
This test works fine in the presence of an IM account. It only catches two cases: caller passed duplicate accountIds, or caller passed an accountId that corresponds to no known account. Geoff, can you confirm that this is covered by your tests?

> I don't quite like that there'd be two ways to sort. The grouping by account type is a bit odd I think: the order the account were in the list makes more sense, and then if the default is changed, we could just move that to the top of the account ids in that list. Then we should just otherwise too allow rearranging the order by dnd
The scope of this bug is exclusively to provide a MailExtension API entry point for "Manually Sort Folders", currently the fourth most-popular addon with 200,000 users, so that it can keep working with future versions of Thunderbird. From what I read on MDN, the process is that if some API is missing, addon authors can ask for new MailExtension APIs to support their use-cases. Rather than just asking, I worked out a prototype patch, which was then improved tremendously by Geoff and Aceman. We then reached consensus on what the API should look like. The API is sound (addons cannot break the internal invariants), it has no effect on the default behavior of Thunderbird, and 100% foots the bill for the purposes of what my addon needs.

I understand and appreciate that having a built-in solution would be much better, but to me this means opening up a different bug, and finding someone ready to commit the cycles and make this a built-in feature of Thunderbird. In the meanwhile, landing an API we reached consensus on would i) allow me to move on to other missing MailExtension APIs that my addon needs, ii) provide a great way to keep a very popular addon working and iii) would, I believe, be very much in the spirit of what MailExtensions are meant to be.

Thanks!

Thanks for the review, Magnus!

> Looks like you'd run into this for the IM account case? For that, unique and accountIds would be different size

This test works fine in the presence of an IM account. It only catches two cases: caller passed duplicate accountIds, or caller passed an accountId that corresponds to no known account. Geoff, can you confirm that this is covered by your tests?

> I don't quite like that there'd be two ways to sort. The grouping by account type is a bit odd I think: the order the account were in the list makes more sense, and then if the default is changed, we could just move that to the top of the account ids in that list. Then we should just otherwise too allow rearranging the order by dnd

The scope of this bug is exclusively to provide a MailExtension API entry point for "Manually Sort Folders", currently the fourth most-popular addon with 200,000 users, so that it can keep working with future versions of Thunderbird. From what I read on MDN, the process is that if some API is missing, addon authors can ask for new MailExtension APIs to support their use-cases. Rather than just asking, I worked out a prototype patch, which was then improved tremendously by Geoff and Aceman. We then reached consensus on what the API should look like. The API is sound (addons cannot break the internal invariants), it has no effect on the default behavior of Thunderbird, and 100% foots the bill for the purposes of what my addon needs.

I understand and appreciate that having a built-in solution would be much better, but to me this means opening up a different bug, and finding someone ready to commit the cycles and make this a built-in feature of Thunderbird. In the meanwhile, landing an API we reached consensus on would i) allow me to move on to other missing MailExtension APIs that my addon needs, ii) provide a great way to keep a very popular addon working and iii) would, I believe, be very much in the spirit of what MailExtensions are meant to be.

Thanks!