Welcome to Codidact Meta!
Codidact Meta is the meta-discussion site for the Codidact community network and the Codidact software. Whether you have bug reports or feature requests, support questions or rule discussions that touch the whole network – this is the site for you.
"Body is too short" error when posting middle-click-pasted answer with no changes
Something caused posting an answer to fail for me (the web interface just sat there, the "Save Post" button disabled, but nothing further happened). To recover, I copied the text of the answer into a separate window, force-reloaded the page with the question, and then proceeded to select the text in the separate window, middle click in the answer body field to paste it (as is a typical workflow in X11), and again clicked "Save Post".
The result was an error message that the answer body text was too short, and needed to be at a minimum 30 characters.
Except the answer was well over 2000 characters long, so the error message was clearly in error in that case; as further evidenced by the fact that simply re-clicking "Save Post" on the reloaded page allowed the answer to be posted.
It might be related that the preview also didn't update to reflect the pasted content. I have seen that before, in that I have to do something further with the body text for the preview to update, but I haven't before got an error back when trying to save a post in that situation.
1 answer
Fix pushed.
When you save a post, we don't take what you typed into the textbox and convert it to markdown on the server, if we can avoid it (we still have to if the client has JS disabled). There's this live preview below the textbox where the HTML has already been calculated for us, so we might as well make use of that; we actually take that HTML and save it instead of re-processing it. This both saves server time and avoids conflicts or formatting differences between client-side and server-side markdown rendering, so it's good all round.
However, that relies on us actually having rendered that markdown client-side at that point. Which, in this case, we hadn't done, because it was only re-rendered on keyup, focus, and markdown events. I've adjusted it to re-render on paste and change as well, so that should capture most changes.
0 comment threads
1 comment thread