Open Bug 1606664 Opened 5 years ago Updated 1 year ago

Add MailExtension APIs to support Manually Sort Folders

Categories

(Thunderbird :: Add-Ons: Extensions API, enhancement)

enhancement

Tracking

(Not tracked)

People

(Reporter: protz, Unassigned)

References

Details

(Whiteboard: [Prio2023])

I am in the process of enhancing or fixing up MailExtension APIs to support a (complete) rewrite of Manually Sort Folders.

This addon was written back when I was young and foolish over ten years ago, and sadly, it consistently registers > 200,000 ADUs and has been ranking #4 most popular addon for a while. Users continue to express a bewildering enthusiasm for the ability to i) sort accounts, ii) sort folders within an account, and iii) choose the default startup folder. I feel beholden to this crowd of enthusiastic users, hence this bug.

I'm enjoying a (short) window to find time to work on this, so here's the current status.

i) For sorting accounts, this is bug 1359410 which should hopefully fixed soon.

iii) For choosing the default startup folder: I have not started to look at it.

ii) For sorting folders, this is a little more complicated and sadly, adding a MailExtension API somewhat implies doing things "right", as opposed to a gigantic addon-side hack. So, I would like to discuss first how to fix things properly.

Folders are sorted here: https://dxr.mozilla.org/comm-central/source/comm/mail/base/content/folderPane.js#2877 -- this defers to C++ almost immediately. The behavior of the C++ code is to perform (via an int-to-string conversion) a lexicographic sort order on the pair (sort-order, folder-name) where sort-order is a special value that allows sorting folders by type (see https://dxr.mozilla.org/comm-central/source/comm/mailnews/base/util/nsMsgDBFolder.cpp#5368) -- Inbox gets special value 0, Drafts 1, etc. and regular folders get 9. Then, the C++ code uses nsICollation (https://dxr.mozilla.org/mozilla-central/source/intl/locale/nsICollation.idl) to perform a case-insensitive string comparison.

This is (in my opinion) overkill and I first propose to switch this to String.localeCompare (possibly preceded by toUpperCase if we want to retain case-insensitivity) and skip the C++ use of nsICollation. This should make it easier to customize the folder sorting behavior.

The question is then how to allow customizing the sort order. The natural answer would be to extend the IDL to allow a custom sort order to be set, i.e. make SortOrder settable (see https://dxr.mozilla.org/mozilla/source/mailnews/base/public/nsIMsgFolder.idl#411); I guess the custom value would then be stored in the .msf file?

However, I seem to remember that Mork is meant to be eventually phased out; also, .msf files are supposed to be discardable and easily reconstructed, correct? So, it doesn't seem to be the best idea to store important information in there (users of the addon would lay into me if they lost their precious sort order).

So, the other way to go about it is to add a dedicated preference (stored as JSON) that maps folder URIs to custom sort values. Then, if there is a custom sort value, it takes precedence over the default, nsIFolder-provided sort order. The folderPane.js sort function could then listen for updates to the preference, and we would still get a total sort order if we sort lexicographically.

The MailExtension API would then work just like the account one, where folders.setOrder(folder, <list-of-subfolder-URIs>) either resets the order if the list is empty, or sets it if the list is non-empty.

I would like some feedback as to which solution is most likely to be reviewed positively and accepted. I am strongly leaning towards the latter solution (JSON pref), because I can implement it relatively easily -- I would need someone else to help if the .msf solution is the only way.

Thanks,

Jonathan

Flags: needinfo?(geoff)
Flags: needinfo?(acelists)

Magnus, I could also use your thoughts about this :). Thanks!

Flags: needinfo?(mkmelin+mozilla)

This isn't really my territory, but I'd suggest the best place to store the information might be folderTree.json. I think its only current use is listing folders that aren't collapsed in the tree, but I don't see why it can't be used for other things too.

Flags: needinfo?(geoff)

Thanks Geoff. Who would be the module owner for folderTree.json and/or able to comment on this?

Quite tricky yeah, but agree folderTree.json could be a good place to put it. Due to different views etc, maybe just an integer (sortOrder) for the specific folder should be saved.

Flags: needinfo?(mkmelin+mozilla)
Flags: needinfo?(acelists)
Severity: normal → S3
Whiteboard: [Prio2023]
You need to log in before you can comment on or make changes to this bug.