Preview and Submit look different
(1) By ddevienne on 2020-04-22 11:23:39 [link] [source]
This post shows the second line correctly in Preview (the two backtick'd portions on
the same line are OK), while after submit, the whole line is in monospace code font.
Small bug?
(2) By Richard Hipp (drh) on 2020-04-22 11:32:19 in reply to 1 [link] [source]
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....
(3.2) By Richard Hipp (drh) on 2020-04-22 12:16:17 edited from 3.1 in reply to 2 [link] [source]
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:
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.
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.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.
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.
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?
(4) By ddevienne on 2020-04-22 11:54:36 in reply to 3.0 [link] [source]
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.
(5) By Stephan Beal (stephan) on 2020-04-22 13:28:56 in reply to 3.2 [source]
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.)
(6) By ddevienne on 2020-04-22 13:38:34 in reply to 5 [link] [source]
(Received from IPv6 sqlite.org, creating separate GMail thread from original IPv4 one, FWIW...)
(7) By Richard Hipp (drh) on 2020-04-22 13:41:44 in reply to 6 [link] [source]
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?
(8) By Stephan Beal (stephan) on 2020-04-22 13:44:39 in reply to 7 [link] [source]
It's happening in gmail, in any case, but intermittently, not consistently. Can't speak for any other mail client, though.
(9) By anonymous on 2020-04-22 13:46:24 in reply to 7 [link] [source]
(13) By Richard Hipp (drh) on 2020-04-22 16:20:11 in reply to 9 [link] [source]
New fix is available. See forum post 732597f6da for details.
(10) By anonymous on 2020-04-22 13:52:21 in reply to 7 [link] [source]
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).
(11) By anonymous on 2020-04-22 14:32:07 in reply to 10 [link] [source]
This is the same "replying to a post which has since been edited" thing, is it not? Was "7" actually a reply to "6", or to "5", or to "3" -- those three are the variously-edited versions of the same post. https://fossil-scm.org/forum/forumpost/bb906aa6ab?t=y shows the history; https://fossil-scm.org/forum/forumpost/bb906aa6ab https://fossil-scm.org/forum/forumpost/04e5ea0d88 https://fossil-scm.org/forum/forumpost/7bc9c71caf all end up at the same content. (It looks like "7" was a reply to "5", if I have the hashes ordered correctly there.) The first mail will have the Message-Id of the first one (because that is when the mail is sent); it looks like generated reply mails get an In-Reply-To of what the then-current version on the forum is (because that reflects the truth), even though a mail with the matching Message-Id was never sent (now that updates to a forum post do not (always) lead to a new email). There probably is not one obviously-correct answer. The mail-sending part *could* make the In-Reply-To include the hash of the original version of the message always (which would be misleading but would preserve threading); perhaps the mail-sending part could make the Message-Id of updated-forum-messages be the same as the first Message-Id (making them non-unique; which may or may not matter to people). It might be an IPv4/IPv6 thing, but it doesn't feel like it should be.
(12) By anonymous on 2020-04-22 15:00:45 in reply to 11 [link] [source]
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?
(14) By Richard Hipp (drh) on 2020-04-22 17:08:24 in reply to 3.2 [link] [source]
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.
(15) By anonymous on 2020-04-22 17:17:22 in reply to 14 [link] [source]
The post arrived in the correct thread in my e-mail client. Thank you!
(16) By Stephan Beal (stephan) on 2020-04-22 18:45:21 in reply to 14 [link] [source]
Viewers with threaded email reader: please confirm...
Confirmed as well.