Bugzilla

We ended up to have no need for any special handling of `nsTArray<RefPtr<T>>`. This means all existing comparators that worked with the `NS_QuickSort` implementation of `nsTArray` should also work with the `std::sort` based one out of the box as expected.

There is one exception to this: `std::sort` can call the comparator with left and right referencing the very same element (I assume they can optimize away an `if` this way when looping), which is something the old `NS_QuickSort` did never do and might lead to problems if the comparator is not prepared for it or even explicitly asserts the two elements are different instances. But those problems did already fall out when landing bug 1839051.

So I do not think there is too much left to do for this bug, once bug 1839051 sticks for a while without specific regressions in necko.

We ended up to have no need for any special handling of `nsTArray<RefPtr<T>>`. This means all existing comparators that worked with the `NS_QuickSort` implementation of `nsTArray` should also work with the `std::sort` based one out of the box as expected.

There is one exception to this: `std::sort` can call the comparator with left and right referencing the very same element (I assume they can optimize away an `if` this way when looping), which is something the old `NS_QuickSort` did never do and might lead to problems if the comparator is not prepared for it or even explicitly asserts that the two elements are different instances. But those problems did already fall out when landing bug 1839051.

So I do not think there is too much left to do for this bug, once bug 1839051 sticks for a while without specific regressions in necko.