I agree to an extent, Omar, but that only prevents the problem of extraneous tags occurring in posts from that point onwards - it doesn't have any effect on those posts which have already been posted, so there's still a use case for my plugin, and perhaps even for incorporating its code into the core.
I say "to an extent" because sometimes when rich-format text is pasted into the editor, it is
necessary that font, size, and/or color tags be added so that the formatting is preserved. In this case, we should simply ensure that if the added font tag contains a list of fonts, any individual fonts in that list are not enclosed in double quotes but rather in single quotes.
I'm not sure that I'll have any success but I'll see if I can work out why SCEditor is adding extraneous tags and how to stop it - noyle seems to have given us a good clue - as well as how to ensure that it uses single quotes instead of double quotes in the list of fonts in those font tags that
can't be eliminated.
OK, I've done a bunch of debugging and testing, and here are the results. Noyle, you're probably way ahead of me on this, so please let me know how this compares to your own findings.
I think that there are three distinct - though related - problems raised in this thread and the one to which nixer55 linked above:
- The 'redundant tags on paste of unformatted text' bug.
Description: In WYSIWYG mode, on pasting unformatted text into the editor which was cut/copied from elsewhere within the editor, some browsers (e.g., Chrome and Microsoft Edge) generate redundant font+size+color attributes in the paste data whose values reflect the editor's default style (based on the default stylesheet jscripts/sceditor/styles/jquery.sceditor.mybb.css). Other browsers (e.g., Firefox) don't, and are not subject to this bug. This confirms noyle's observation/finding above. It is also the bug to which Omar's suggestion above applies: let's disable the addition of these tags. And it is the first aspect of the bug identified in the post to which nixer55 linked above.
How to reproduce: In Chrome or Microsoft Edge, bring up a new editor window through a page such as a New Reply page. Deselect Source mode if it is selected, such that the editor is in WYSIWYG mode. Now, type some text into it, such as "Blah". Do not style or format that text in any way. Now, select it all, cut it, then immediately paste it, and switch to Source mode. You will see that it has had font, color, and size MyCode tags added to it even though it was unformatted and unstyled prior to being pasted, and thus should not have had any MyCode tags applied to it.
Impact: Mild-moderate. Not detectable in WYSIWYG mode (except in the form of bug #2 below); irritating when switching to Source mode.
- The 'reduced size on paste of unformatted text' bug.
Description: As above, but with the added observation that under those same prone browsers (e.g., Chrome and Microsoft Edge), when the unformatted text cut/copied from elsewhere in the editor in WYSIWYG mode is pasted back into it, its default size of 14px (redundantly generated in the pasted data by these browsers) as styled by the default stylesheet (jscripts/sceditor/styles/jquery.sceditor.mybb.css) does not match any of the sizes supported by MyBB's customisation of SCEditor, such that the editor picks the "best fit" out of those sizes, which is in fact smaller than 14px. Again, other browsers (e.g., Firefox) aren't affected, again confirming noyle's observation/finding above. This is the second aspect of the bug identified in the post to which nixer55 linked above.
How to reproduce: As above, but note that before switching to Source mode, the pasted text "Blah" is smaller than it was when it was cut. Also note that after switching to Source mode, the default attribute of the size tag is "small", rather than the size specified by default stylesheet, "14px" (and thus infer that "small" and "14px" are different font sizes).
Impact: Mild-moderate. It is annoying in WYSIWYG mode to have to re-select such pasted text and click the "Remove Formatting" button to get it back to its original (unformatted) size.
- The 'double quotes in font lists' bug.
Description: Sometimes, in scenarios the criteria of which I haven't yet rigorously identified, when pasting text into the WYSIWYG editor, its specified font is actually a comma-separated list of two or more fonts, and at least one of the fonts in that comma-separated list is enclosed in double quotes. When the post is posted, the associated MyBB font tag(s) is/are not rendered by MyBB's PHP parser, because that parser doesn't support double-quotes within the comma-separated list of fonts of a MyCode font tag. (This is the bug which my plugin above addresses for posts which have already been posted).
How to reproduce: In any browser, bring up a new editor window through a page such as a New Reply page. Select Source mode. Paste the following MyCode into the editor, after first replacing the curly braces with square braces (since I am posting this on a MyBB forum, I can't paste valid MyCode tags as they would then be rendered):
{font=Test, "Test two"}Blah{/font}
Switch out of Source mode and then back into it. Confirm that the code has not changed. Then submit or preview the post. Notice that in the rendered post, the raw font tag shows up unrendered.
Impact: Moderate-severe. There can at times be so many of these unrendered font tags that the post once posted is effectively unreadable.
A working solution and a potential but flawed solution:
Let's start with bug #3, the 'double quotes in font lists' bug, because its solution is simplest with fewest potential side effects. Borrowing from and porting into Javascript the PHP code of my plugin above, we can simply replace in the file jscript/bbcodes_sceditor.js the following code from within the "format" method relating to the "font" bbcode:
return '[font=' + this.stripQuotes(font) + ']' + content + '[/font]';
with this:
if (font[0] == '"' && font[font.length-1] == '"' && (font.match(/"/g) || []).length == 2) {
font = font.substr(1, font.length-2);
}
font = font.replace(/"/g, "'");
return '[font=' + font + ']' + content + '[/font]';
Now, when text is pasted into the editor in WYSIWYG mode, or when switching into Source mode, double quotes within lists of fonts are replaced with single quotes. Problem solved.
Bugs #1 and #2 are closely related in that they stem from browsers redundantly setting values for style attributes in pasted text that are already at their default values. The "obvious" fix is to again edit appropriate sections of jscript/bbcodes_sceditor.js such that default values of those size/font/color attributes are detected and ignored, and so that no tag is thus added in those scenarios. I have tested this approach - for size, font, and color tags - and it
does work on a default MyBB installation, resolving both bugs. The problem, however, is that it involves hard-coding those default style values into this Javascript file based on those in the default stylesheet, jscripts/sceditor/styles/jquery.sceditor.mybb.css, whereas, as Hovatek's scenario above demonstrates, those default stylesheet values might be changed (customised) by themes. That is to say that, for example, the default font-family specified in jscripts/sceditor/styles/jquery.sceditor.mybb.css is 'Tahoma, Verdana, Arial, Sans-Serif', whereas for Hovatek's forum it appears instead to have been customised to '"droid sans", sans-serif'. Detecting and ignoring in Javascript the default font-family for the editor as specified in jscripts/sceditor/styles/jquery.sceditor.mybb.css would thus fail on Hovatek's forum, because his theme has overridden that default font-family.
So, I wonder whether anybody has any good suggestions for how to more generally resolve bugs #1 and #2?