Bugzilla

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 (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.

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.