1927877 - [ews] Replying to, or forwarding a message does not quote the original message

Status: RESOLVED FIXED

(Thunderbird :: Account Manager, defect)

Description

[Brendan Abolivier [:babolivier]]

There are two things missing for this to work:

First, nsMsgQuote::QuoteMessage calls nsIMsgMessageService::GetUrlForUri, which for EWS returns the result of NS_NewURI, and uses the return value of that method to create a channel (nsIIOService::NewChannel). For EWS, the source URI is a message URI with the ews-message protocol scheme, which cannot be used to create a channel.

This might be fairly easy to fix by replacing the call to NS_NewURI in nsIMsgMessageService::GetUrlForUri with a call to EwsService::NewURIForChannel. Although I'm not sure if the output of GetUrlForUri is used for something other than opening a channel, in which case solving this might be a bit more complicated.

Second, nsMsgQuote::QuoteMessage attempts to convert the output from the channel to HTML, except EwsMessageChannel already converts to HTML. This is tricky to skip because nsStreamConverter sets the content type of the channel to HTML upon init if the current context is about quoting (which sounds to me like a misuse of the nsIChannel API). This causes the message content to go through two conversions (and end up mangled).

In my tests I was able to skip the conversion in EwsMessageChannel by noticing that the listener returned by nsIStreamConverterService::AsyncConvertData is an nsIStreamConverter, and skipping conversion if I could QI to this type. This made quoting work, but this isn't a stable solution. Another solution could be forcing the content type of the channel to message/rfc822 after the stream converter is set up, but I'm not sure what negative side-effect this would have on other protocols.

Comment 1

[Brendan Abolivier [:babolivier]]

This will require adding the possibility to use a channel for message download. After discussing the best approach, we've decided we'll implement a dedicated nsIChannel implementor for message download, which will instantiate and open an EwsOfflineMessageChannel once the message has been downloaded.

As a drive-by improvement, this will allow us to support the aConvertData argument of nsIMsgMessageService::StreamMessage, which we need to correctly render the multi-message view.

Comment 2

[Brendan Abolivier [:babolivier]]

Attachment: WIP: Bug 1927877 - Use a channel for EWS message download. r=leftmostcat

This refactors the message download code for EWS by encapsulating it into an nsIChannel implmentation, so that operations like quoting can work on messages that haven't been downloaded yet.

I've also made EwsService::GetUrlForUri return an x-moz-ews URI since there doesn't seem to be any expectation in the code that its return value is a *-message URI (e.g. IMAP returns imap URLs), and it means code that isn't EWS specific can instantiate channels with the correct URI for it.

I think channels should ultimately expect to only deal with x-moz-ews URIs, but since channels use EwsService::MessageURIToMsgHdr to retrieve a database entry, and it needs to support *-message URIs since the frontend might use it for things other than opening channels, we indirectly and implicitly also support *-message URIs in channels for now.

Comment 3

[Brendan Abolivier [:babolivier]]

Attachment: Bug 1927877 - Download EWS messages in an nsIChannel. r=BenC,mkmelin

This patch introduces the OfflineStorage files in mailnews/protocols/common,
which are meant as protocol-agnostic helpers for reading a message from an
offline store (since the logic for this doesn't really need to be
protocol-specific).

Comment 4

[Brendan Abolivier [:babolivier]]

Note to sheriffs: Please land at the same time as bug 1942830 (since both patches are stacked together)

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/59e19809ddb6
Download EWS messages in an nsIChannel. r=BenC,mkmelin