Mail: Replying to HTML message in plain text misses > characters

[jancborchardt]

I’m getting an HTML mail and reply in plain text only. The mail looks like this for example:

Hello,

this is a message. 

Expected

When I reply or forward, the message is prefilled into the field like this:

"Name" [email protected] – 20. Februar 2020 12:15
> Hello,
> 
> this is a message. 

What actually happens

There are no > characters at all which would separate the original message from my reply:

"Name" [email protected] – 20. Februar 2020 12:15

Hello,



this is a message. 

Setting to priority as this makes replying to HTML mails very cumbersome.

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[ahstro]

I've been giving this a cursory glance, and running this.originalBody through htmlToText before sending to buildReplyBody gives the output we'd like. Then it'd be a matter of getting access to the editor mode in NewMessageDetail.vue and formatting accordingly.

However, this might be a red herring, since I realized that when toggling "Enable formatting", the quotes disappear. Not sure if we want to tackle that directly somehow, or if we want to close this issue ASAP?

[ChristophWurst]

Thanks a lot for looking into this issue.

Regardless of this specific bug, I have the feeling that our handling of plaintext, HTML text and the conversions between those two is very fragile. We've had it a few times where we fixed one bug. And at another spot we created three new ones.

So, yeah, we could hack this into the new code. But we're not really solving a problem. As we don't have a new release in sight as long as https://github.com/nextcloud/mail/projects/9 doesn't work reliably, we got some time to do it right :)

IMO we need a better abstraction of text. Also we should revisit on which level we have which type of text.

I have not put much thought into this yes, but what about a little rich object like

{
    type: 'html',
    encoded: true,
    value: '...'
}

and changing the current conversion helpers and components to consume and emit this structure. Then we are more aware of what the value we're passing around represents. And we can unit tests (some) of the logic.

@ahstro what do you think? Does that sound reasonable?

[ahstro]

Yeah, I completely agree that a better abstraction of text would be nice! Not just passing along strings and counting on context, but having a dedicated _type_ feels like a great improvement to me 😁

Just thinking out loud here: I was pondering the possibility of having a single source-text and interacting with it differently depending on user settings. E.g. if we stored the text in HTML, and a users started typing a >, that would be stored as a <blockquote>. I'm not sure how feasible it is, but that way, conversion would be as simple as choosing how to render the source-text (and as complicated as choosing how to update it).

[ChristophWurst]

I was pondering the possibility of having a single source-text and interacting with it differently depending on user settings. E.g. if we stored the text in HTML, and a users started typing a >, that would be stored as a <blockquote>. I'm not sure how feasible it is, but that way, conversion would be as simple as choosing how to render the source-text (and as complicated as choosing how to update it).

The HTML should be generated by the rich text editor usually. So that could either already replace > with <blockquote> (though it will more likely use &gt) or we could add it as a plugin. Is > always a blockquote, though? :thinking:

[jancborchardt]

Any decision on this? :) Currently this still makes replying to HTML mails unusable.

For the case where it happens to me, namely replying to HTML mails in plain text, simply putting > (a > and a space) before each line of the original message would solve the issue perfectly.

[ChristophWurst]

As mentioned in https://github.com/nextcloud/mail/pull/2838 I think I know why this happens. We take the original text, build an HTML reply from that (with a <blockquote>), but the editor just removes the blockquote as non-supported element in the plain text format.

The following logs confirm that.

@jancborchardt could you try to reproduce one more time and see the logs then. You should see a blockquoted text replaced by one without like in my screenshot.

[jancborchardt]

@jancborchardt could you try to reproduce one more time and see the logs then. You should see a blockquoted text replaced by one without like in my screenshot.

@ChristophWurst yes, can confirm this behavior on current master.

[ChristophWurst]

In addition to the discussed problem of how we handle different kinds of text in code I found that we probably have to move some logic around to make this less error-prone. Working on this right now. Stay tuned.

[ChristophWurst]

Fix is at https://github.com/nextcloud/mail/pull/2874.