Editor issues

The editor on the forums seems to have a number of automatic actions that harm the integrity of posts being made. I know that these issues are not present on SV and SB, and since all three forums are XenForo-based, this should be fixable.

1) Pasting text into the rich editor (but not the BB Code version of the editor) will strip out all blank lines. That means blank lines inserted between paragraphs for readability are removed, making all of the text collapse together. It also strips out extra spaces, including spaces that should have gone into a preformatted text block (text enclosed in [code] tags), mangling the original attempt at formatting.

2) Preformatted text (text enclosed in [code] tags) converts continuous runs of spaces into tabs. This wouldn't be quite as bad if the default tab width on display wasn't different from the number of spaces that were converted to tabs. It seems to convert every group of 4 spaces into a tab, but then display text with a tab width of 8 spaces (browser default). Either it should not be converting spaces to tabs in the first place, or the CSS should include info on the actual tab size of 4 rather than 8 (-moz-tab-size, -o-tab-size, tab-size; IE does not support this), or it should be converting groups of 8 spaces at a time to match browser defaults of an 8-space tab.

Note that the above mangling is done even when editing using the BBCode editor rather than the rich text editor.

3) The editor appears to strip other characters out, such as the zero-width space.

This line:
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaabbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb

Should have a zero-width space between the a's and the b's, causing the two segments to each appear on their own line (as long as the window is narrow enough to force a word wrap). It behaves that way in the editor, but strips the character out of the preview and post.


Certain parts of this problem are the editor itself, as it behaves while running in the browser, and certain parts are due to modifications it makes on the back end, after posting. There are too many modifications being made to the post by the forum.

 

Ah yes; the source of much frustration.

At least if "paste as plain text" was disabled by default...

Still, you can avert most of the formatting disasters by using Ctrl+V instead of the mouse interface.

Also other problem, when I'm using my iPad sometimes the RT editor's buttons will be changed to random images (ponies, rainbows, etc...)

 

It gets worse? I've never used anything but Ctrl+V for pasting.

Ahhh. Interesting. I hadn't noticed that toggle before.

Yes, turning it off allows pasted text to not be stripped of blank lines. Nice. I'm not sure how it affects the other issues.

Code:

0		   1		   2
1		   1		   2
2		   1		   2

OK, it doesn't strip the spaces out when pasting, but it still converts runs of spaces to tabs.

 

Oddly, if you copy and paste from a word processor, it doubles the returns between paragraphs.

 

Very strange. If I copy the same text from Word (three lines with blank lines in between), pasting into this editor preserves the blank lines regardless of the Paste As Text setting. However if I paste them into a text editor and then copy from there, pasting them into this editor strips the blank lines when Paste As Text is on, but keeps them when it's off.

Looking at the raw clipboard contents, it seems to be identical in each case: a newline (\n) at the end of each line (both sentences and blank lines). Changing \n to \r\n (DOS format newlines) does not change anything; pasting with Paste As Text on still strips the newlines if they came from the text editor. Changing from ANSI to Unicode source doesn't change anything. Pasting with two blank lines between paragraphs removes only one of them, however, leaving the desired one blank line between paragraphs.

Digging in further, the paste module for the page seems to have a bunch of code for handling stripping out MS Office stuff from a text/html formatted paste, which is one of the clipboard elements created when copying from MS Word. A text editor of course doesn't have that, and only creates CF_TEXT and CF_UNICODETEXT objects on the clipboard.

Searching for the plugin, it looks like it's the TinyMCE Paste plugin (part of TinyMCE Enhancements, which is no longer supported, and TinyMCE Quattro). I would guess that we want it to default to Paste As Text, rather than trying to parse MS Word markup. I also suspect it would be easy to fix for the person who wrote the code; I just don't want to dig any deeper into minimized javascript.

It may also be subject to variances between browsers. I'm using Firefox.