There was an unclosed <code> element in a prior post that was leaking out into subsequent posts. I fixed this instance of the problem by editing the problem post to insert the missing </code>.

I'm not sure of the best way to implement an automatic fix to this kind of problem....

And, in particular, my "fix" only works for the hierarchical view. In the chronological view, the original unedited posting is still shown (grayed out) and so there is still a missing </code> that messes up the formatting on everything that follows.

Possible fixes:

1. Enhance the Markdown formatter so that it recognizes and tracks embedded HTML and ensures that all needed close-tags are present. This will likely be a lot of code.

2. Put each post in a separate <iframe>. This would mean that each post would be fetched using a separate HTTP request, which would slow down rendering, and dramatically increase the server load. I think we can safely dismiss this idea, unless somebody knows of an iframe trick to make it work without requiring a separate HTTP request for each message.

3. Do not show the text of deleted or edited posts in the chronological view. Instead, include a forward reference to the most recent version, or a note to say that the post was deleted.

4. Show deleted or edited posts as text/plain in the chronological view → This is now on trunk for the 2.11 release, as the change was small and low-risk. We can perhaps change to option (3) after 2.11, if we later judge that to be a better approach.

5. Show deleted or edited posts as text/plain in the "history" view. This should perhaps been done independently of whether or not we decide on (3) or (4) above. Perhaps all entries should be shown as text/plain for the history view. This was a one-character change to the source code, so it has now been implemented and uploaded and will be part of 2.11. You can test it by clicking the [history] link on this post.

Question:

Is this a problem that ought to be fixed prior to the 2.11 release? Or should we hold off and fix it after the release?

Is this a problem that ought to be fixed prior to the 2.11 release?

Probably not. I'm just picky, that's why I notice and report it, but I suspect most people don't mind :) This can wait.

It's amazing that that hasn't bitten us yet. The text-only history is definitely a good idea. IMO that's good enough for the next release, but we should consider alternatives/additional actions for the next cycle.

Try adding an opening TEXTAREA tag without a closing tag, tap Preview, then try to edit the resulting preview (spoiler alert: the buttons no longer work).

Curiously, an errant closing BODY or HTML tag do not appear to break anything. (My concern was that a malicious poster could post a message which we effectively could not moderate because the page ended prematurely.)

Iframes would be the only "real" workaround, but they would be disastrous in terms of performance/efficiency. A full-fledged HTML-aware parser would be a huge hassle to implement and maintain.

Iframes apparently now support a "srcdoc" attribute which would allow us to embed iframes along with their source content, as opposed to requiring separate requests for each:

https://html.spec.whatwg.org/multipage/embedded-content.html#attr-iframe-srcdoc

(See the example on that page.)

However, no versions of MSIE support this:

https://caniuse.com/#feat=iframe-srcdoc

Though newer versions of Edge do. (93% of worldwide client browsers support it, according to the top/right of that page.)

(Received from IPv6 sqlite.org, creating separate GMail thread from original IPv4 one, FWIW...)

Is this really a bug in Postfix (the sqlite.org mail agent) or in the configuration thereof? Or is it a bug in your email reader, that makes it think that elements of the same thread can't possibly originate from two different IP addresses?

It's happening in gmail, in any case, but intermittently, not consistently. Can't speak for any other mail client, though.

I think it's neither. The In-Reply-To: header again references a Message-Id that my e-mail client does not have.

To be precise, 1 is <085a52738c1879f3bdf596e77939b4ac@fossil-scm.org> but 7 is In-Reply-To: <04e5ea0d88e6371d50415a1d557734b4@fossil-scm.org>.

Sorry, I should have said that 7 is In-Reply-To: <04e5ea0d88e6371d50415a1d557734b4@fossil-scm.org>, but 6 has Message-Id: <bb906aa6ab5f0e881d164fafda881f72@fossil-scm.org>. 1 is upthread and should not be referenced in this case (unless one is to use the References: header, which is something completely different).

The mail-sending part could make the In-Reply-To include the hash of the original version of the message always

That is what is supposed to be already happening...

Perhaps we should go back to the original bug report thread to avoid further topic drift?

New fix is available. See forum post 732597f6da for details.

Viewers with threaded email reader: please confirm that this follow-up to the post with three edits is linked into the correct thread.

The purpose of this post is to verify that the In-Reply-To: fix discussed at post 732597f6da is actually working.

The post arrived in the correct thread in my e-mail client. Thank you!

Viewers with threaded email reader: please confirm...

Confirmed as well.