• Do not register here on develop.twiki.org, login with your twiki.org account.
• Use View topic Item7848 for generic doc work for TWiki-6.1.1. Use View topic Item7851 for doc work on extensions that are not part of a release. More... Close
• Anything you create or change in standard webs (Main, TWiki, Sandbox etc) will be automatically reverted on every SVN update.
Does this site look broken?. Use the LitterTray web for test cases.

Item5702: The newline eating bug is back again

Item Form Data

AppliesTo: Component: Priority: CurrentState: WaitingFor: TargetRelease ReleasedIn
Extension WysiwygPlugin Normal Confirmed   patch  

Edit Form Data

Summary:
Reported By:
Codebase:
Applies To:
Component:
Priority:
Current State:
Waiting For:
Target Release:
Released In:
 

Detail

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 smile

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

ItemTemplate
Summary The newline eating bug is back again
ReportedBy TWiki:Main.KennethLavrsen
Codebase ~twiki4
SVN Range TWiki-5.0.0, Sun, 01 Jun 2008, build 16865
AppliesTo Extension
Component WysiwygPlugin
Priority Normal
CurrentState Confirmed
WaitingFor

Checkins

TargetRelease patch
ReleasedIn

Edit | Attach | Watch | Print version | History: r10 < r9 < r8 < r7 < r6 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r10 - 2008-06-16 - KennethLavrsen
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback