Rendering not ignoring blockquotes in email quote replies with contents that were rendered with Markdown Here Revival
Summary
If you use Markdown Here Revival to render something, it stores the fact that you did that as well as what plain text it used to be in HTML using fancy divs and stuff so that it's able to unrender it. If you send the email, that data isn't removed (I think it should be, but that's a separate issue and there's probably a reason it's not).
If someone else receives that email and also uses Markdown Here Revival (or you just send it to yourself), and is replying to your email (with email quoting enabled), and then tries to render their email, it will also try to re-render your original email, even though it's in a blockquote (the email quote reply) and it's supposed to ignore blockquotes.
The re-rendering breaks stuff, though. Some things I've noticed break are:
- Some spacing in text paragraphs gets removed.
- The 2nd space (from my testing) in text paragraphs gets removed. It happens with quotes too sometimes (it seems to be inconsistent, I don't know why), but it happens from the other side (2nd space from the right instead of 2nd space from the left).
- For example:
Some **bold** test message
becomesSome **bold**test message
. - This is how I originally noticed this bug. If you do this enough times, you can effectively remove nearly all of the spaces in your (heavily nested) quoted replies and it becomes very difficult to read due to the lack of word separation.
-
h1
titles have the line below them removed. - Quotes (markdown ones, not email reply ones) have their coloured left margin line thing removed.
Steps to reproduce
- Send an email to yourself with the following content (rendering it before clicking "Send"):
# Title with spaces
> a quote with spaces
Some **bold** test message
- Click on the "Reply" button for that email, and then click the render button.
- You can type stuff above the quote too if you want (normally you would of course), but you don't actually need to do that for it to break.
- See that the quote was re-rendered and is now broken, looking roughly like this:
# Title with spaces
*(there is no line here!)*
> a quote withspaces
*(in this specific example in my testing the space didn't disappear, but this has happened in other tests)*
Some **bold**test message
- If you check the HTML of the message (for example, using ThunderHTMLedit), you can see what it did.
- It added an MDH wrapper div inside the email body around everything, and an MDH exclusion div around the blockquote email reply.
- However, that MDH exclusion div also has an MDH wrapper div in it from the original sender, and the contents of that div is what breaks.
- Doing this also reveals another possibly related issue, which is that the base64-encoded plain-text "undo" thing that was just added as part of the replying email includes HTML of content that should be excluded (the contents of blockquote).
- I don't think there's a reason to store that since it shouldn't be touched anyway, and because it's base64-encoded HTML it's rather long so is wasteful of email file-size, although that specifically is an unrelated issue.
- Basically this means it's processing stuff it shouldn't, I think. It should just see a blockquote element and skip over it, not check inside it at all.
Workaround
You can get around this by selecting everything you wrote above the quoted reply and then rendering it, as doing it that way will only render the selection (this also avoids #44 (closed)). This isn't a good solution though because it's pretty easy to forget to do that and accidentally break a quote.
Versions
- Thunderbird version: 102.1.2
- Markdown Here Revival version: 3.4.2
- Operating system: Windows 10