Item5702: The newline eating bug is back again

The newline eating bug is back again

If you have a verbatim block and no while space line after the end verbatim - the Wysiwyg editor is again eating the newline after the verbatim block

I am entering this bug report in raw edit.

And then edit and save in Wysiwyg using IE forcing a new revision so rev 2 is after the Wys save.

Some text inside the verbatim

Some text on the line just below the /verbatim

Let us test some other html tag

cell

Some text just below a /table with a width so the Wysiwyg does not turn the html table into TML

Let us see the result now

-- KennethLavrsen - 13 Jun 2008

Now saving in Wysiwyg mode

KJL

3rd edit in raw mode. As can be seen in raw mode the Wysiwyg editor again eats newlines right after a html or html-alike tag if there is no empty line after the tag.

This will cause trouble when the line following has a content that requires that it starts on its own line to work.

KJL

4th edit in raw edit mode and saving new version.

I will now try and show if there are severe consequences

The things I can think of are bullets, headings and TML tables that all require that the next line begins on a new line. A table is often the result of a search. Instead of a search I just simplify things by using a twikivar

Trala

• This bullet must survive
• 2nd bullet

  Trala
  

Heading 4 must survive

Trala

table cell

Another cell

• Set TRALA = | some table | with some cells |

  Trala
  

some table

with some cells

and now saving this in raw editor again with new revision forced.

KJL

Saving in Wysiwyg forcing new rev.

KJL

I am happy to see that in all the 3 examples the newline eating bug does not manifest itself.

Now in raw edit let me just check one more thing. Trying with a dummy tag.

Below a dummy tag

• Bullet

below a dummy tag

Header 4

Below a dummy tag

some table

with some cells

Below a dummy tag

table

tables

One thing I forgot in the previous test is a wiki word.

First with verbatim

trala

WebHome

Then with dummy tag

WebHome

KJL

Note that the new line eating bug also eats newlines BEFORE the html tag. And in one case a life saving space is added between the tag and following text. Interesting. But this happened only with the dummy tag. Not with verbatim.

KJL

Saving from Wys forcing new rev

KJL

Conclusion we have a new line eating bug. And it causes trouble when the first word on the next line is a wikiword. In other cases the newline eater does not eat or the eating seems harmless.

It is not uncommon to start a line with a wikiword so it would be best if the newline after a "lt/gt" tag is not eaten. it is at the borderline between urgent and non urgent. I start with urgent until Crawford evaluates how difficult it is to fix.

-- TWiki:Main.KennethLavrsen - 13 Jun 2008

Which came first, the dinosaur or the egg?

I believe this may be a direct result of the previous problem you marked as urgent (extra space after </ul> in firefox) though it requires some more investigation. While I really do appreciate the analysis, it's not clear from the above stream of conciousness exactly what you are reporting as a bug. Is it a wikiword immediately following an HTML block tag? If so, this is a direct counter-example of the firefox problem you reported. I fear the solutions are mutually exclusive.

-- CrawfordCurrie - 14 Jun 2008

Before the dinosaur and the egg there were little nasty bugs crawling around

I had the feeling this one would be tricky.

When we add white space that creates problems. When we remove white space it also creates problems.

The observation here is

• An html type tag followed by ONE new line an then some plain text causes the newline after the html tag to be "eaten".
• An html type tag followed by TWO or more newlines followed by some plain text does not cause the newline after the html tag to be eaten
• An html type tag followed by either a bullet, a table, a TWiki variable, or a heading does not cause the newline after the html tag to be eaten
• Plain text following an html tag does not suffer from the newline to be eaten.

The only case where I see a potential problem is the special case, html type tag (or one of the tags that TWiki has invented such a verbatim) followed by a new line followed by a WikiWord.

If I enter this in Raw Edit

some leading text
<verbatim>
some verbatim
</verbatim>
some trailing text

an edit save trip in Wysiwyg produces this

some leading text
<verbatim>
some verbatim
</verbatim>some trailing text

Trying to save this by adding a space would introduce 10 new problems so that it for sure not a way to fix it.

The ideal is to preserve the newline that was already on the line containing the tag

But this may be diffucult because of the way TMCE works. How will the Wysiwyg know if the new line was there?

Just blindly adding a newline after selected tags like /verbatim can also be bad. For example this would not be possible

hfhfhf

plaiin text

hfhfhf

plaiin text

hfhfhf

plaiin text

Tricky one I know.

One good thing is that if you enter some text in the Wysiwyg and make a block verbatim followed by a line that starts by a wikiword, the Wysiwyg saves an empty line between the /verbatim and the text so a Wysiwyg editing person will rarely run into an actual problem.

Downgrading to normal

-- KennethLavrsen - 14 Jun 2008

I tried to reproduce this on trunk (revision 3794). I cannot.

some leading text

some verbatim

some trailing text

... and ...

hfhfhf

plaiin text

hfhfhf

plaiin text

hfhfhf

plaiin text

... both survive a WYSIWYG edit/save. So I think CrawfordCurrie's recent changes have fixed this problem.

Is there an aspect of this problem that I missed?

-- MichaelTempest - 02 May 2009