662367 - Move into JSMs functions that shouldn't require a 3-pane

Status: ASSIGNED

(Thunderbird :: Mail Window Front End, defect)

Description

[Jonathan Protzenko [:protz]]

Some functions defined in mail/base/content either:
- require a mail:3pane to be open although it makes no sense for them to do so, hence making them inaccessible unless a 3pane is open, or
- operate on selected messages, thus requiring extension authors to rewrite their own copies of the thing to operate on any set of messages.

Here's a non exhaustive list:
getIdentityForHeader, ViewPageSource, getCardForEmail, AttachmentInfo, HandleMultipleAttachments, openAttachment, saveAttachment, get the phishing detector, MsgFilters, BatchMessageMover

Other functions I designed in thunderbird-stdlib could probably generalize some routines that only operate on selected messages:
- mark messages as read,
- tag a message with an arbitrary set of messages (which implies first removing some tags, then adding other ones)...

I also don't know what's going to happen when we stream messages (e.g. standalone conversation tab) without a 3pane open. What with the msgHeaderSink? What with the msgWindow? I once remember trying to pass my own msgWindow to DisplayMessage, and it failed badly: bad formatting, no smileys... although I need to try again.

There's also bug 561859 that I never had the courage to tackle (and that would definitely require a lot of work).

Comment 1

[Jim Porter (:squib)]

On this subject, I wouldn't mind seeing functions to open a message in a new tab or in a conversation in MailUtils.js.

Comment 2

[Jim Porter (:squib)]

This is only tangentially relevant, but I think I'd like it if getIdentityForHeader was implemented in C++ so that the code I touched in bug 64267 could take advantage of it too.

Comment 3

[Ben Bucksch (:BenB)]

+1

Comment 4

[Jonathan Protzenko [:protz]]

Attachment: WIP patch

Here's a patch with all the work I did so far. The part that bit me was that getIdentityForHeader takes a msgHdr parameter: this hints that the function will return, as one may surmise, the identity for that header. This is a bald-faced lie. The function actually uses a variable that's in the global scope, called currentHeaderData. So this function actually works properly if and only if the header you want the identity for happens to be the currently selected message. I may have shouted "WTF?" at this point :).

The first solution consists in adding the last delivered-to header in the nsIMsgDBHdr, that is, in the msf files, so that the function can recover the correct information. This may bloat the size of the msf files, which we want to avoid as much as possible.

The second solution consists in making this function asynchronous, which will in turn force all other callers to be asynchronous too, which will be a major pain to implement.

I don't remember if I imported all the functions I wanted. There's certainly much work left to do (just for reference, all the functions we may want to import are lying there https://github.com/protz/thunderbird-stdlib) but it's mostly replacing built-in functions so that they use the newer ones (which will in turn make sure the newer ones work properly). Functions like MsgDeleteSelectedMessages or ToggleMessageTagKey are probably covered by tests, and making sure they're just proxies for the newer functions will probably be enough to make sure everything's working fine.

We may want to expose even more functions, like folderIsInbox...