Item8966: Wysiwyg editor breaks standard topics

There are about 500 topics in a standard install of Foswiki (trunk). I ran a test today to see how many survived being edited by TMCE, such that the meaning did not change - and only about 200 survived. Around half were definitely corrupted.

My test has problems, so the numbers are not precise. However, there is clearly a large problem if approximately half of the topics that ship with Foswiki would be corrupted by editing them with the default editor. The WysiwygPlugin and TinyMCEPlugin have plenty of room for improvement, but it is easy to prevent corruption of these standard topics - simply add "* Set NOWYSIWYG = 1" to each affected topic, or enclose the problematic parts in <sticky> blocks.

Test details
The test approach was to open the wysiwyg editor, click WikiText, paste the topic-under-test's content, click WYSIWYG and sample the HTML. Then click WikiText and WYSIWYG and sample the HTML again. If the two HTML samples are different then the WYSIWYG editor definitely corrupts the topic. If they are the same, then the WYSIWYG editor probably does not corrupt the topic. Note that the converting the original topic text to HTML and then back to WikiText will almost certainly produce different text because the conversion eats newlines (this behaviour is expected) although the newlines that are eaten should not affect the HTML that is produced - this is why the test compares HTML.

This test results are not repeatable because Firefox stopped responding to the WikiText button at some point. I had to intervene manually to let the test continue running, and 43 tests failed before I got that right.

-- MichaelTempest - 02 May 2010

The list of corrupted topics is not static - it changes as WYSIWYG-related bugs are fixed. Changing status to confirmed.

-- MichaelTempest - 27 Jun 2010

Bumping this to urgent. There are probably more than one issue here, and we can protect some topics by settting NOWYSIWYG, but some are more urgent. For example, all <nop> macro escapes were removed when PatternSkinCssCookbook was edited. Ex:

-   * Point the CSS [[%SYSTEMWEB%.PreferenceSettings][preference settings]] in [[%SYSTEMWEB%.%WIKIPREFSTOPIC%]] or [[%LOCALSITEPREFS%]] to your new files:
-<pre class="tml">
-   * <nop>Set FOSWIKI_LAYOUT_URL = %<nop>PUBURLPATH%/%<nop>SYSTEMWEB%/YourNewTopic/layout.css
-   * <nop>Set FOSWIKI_STYLE_URL = %<nop>PUBURLPATH%/%<nop>SYSTEMWEB%/YourNewTopic/style.css
-   * <nop>Set FOSWIKI_COLORS_URL = %<nop>PUBURLPATH%/%<nop>SYSTEMWEB%/YourNewTopic/colors.css
+   * Point the CSS [[System.PreferenceSettings][preference settings]] in [[System.%WIKIPREFSTOPIC%][%SYSTEMWEB%.%WIKIPREFSTOPIC%]] or [[%LOCALSITEPREFS%]] to your new files:
+<pre class='tml'>   * Set FOSWIKI_LAYOUT_URL = %PUBURLPATH%/%SYSTEMWEB%/YourNewTopic/layout.css
+   * Set FOSWIKI_STYLE_URL = %PUBURLPATH%/%SYSTEMWEB%/YourNewTopic/style.css
+   * Set FOSWIKI_COLORS_URL = %PUBURLPATH%/%SYSTEMWEB%/YourNewTopic/colors.css
 </pre>

Looking at this again, also noticed that the first bullet was wrapped onto the <pre line, breaking the bullet.

Also this manifests for anyone attempting to create a personal template. The My Links heading is wrapped onto the prior html comment line. -- GeorgeClark - 23 Feb 2015

Attempting to add a unit test for the above fail. The round-trip is closing the <nop> tags, which is different from the observed fail, the nop's were removed, not closed.

==noppedVariable== Expected TML:
<pre class='tml'>
   * <nop>Set FOSWIKI_LAYOUT_URL = %<nop>PUBURLPATH%/%<nop>SYSTEMWEB%/YourNewTopic/layout.css
</pre>
==noppedVariable== Actual TML:
<pre class='tml'>
   * <nop>Set FOSWIKI_LAYOUT_URL = %<nop>PUBURLPATH%/%<nop>SYSTEMWEB%/YourNewTopic/layout.css

</nop></nop></nop></pre>

-- GeorgeClark - 23 Feb 2015

Commenting is disabled while not logged in