Newline handling awkward (at least in FF 2)

[Jason Winnebeck]

Newline handling seems to be awkward and doesn't render properly some of the time. Please note I only tried this under Firefox 2. When you hit return once it works well. When you do it again it inserts a BR, but it doesn't render it the same as Trac would. At this point, if you switch to textarea (to see source) and back to editor it "eats" space between paragraphs. It seems to do this and eats one more line until paragraphs are separated. While it would probably be a bug that round-trip doesn't produce the same code (switching view and then returning changes content without any editing), it has the nice side-effect of normalizing paragraphs to have 1 blank line between all.

Another thing I noticed is that if there are multiple blank lines between paragraphs it is ignored by Trac but not by TracWysiwygPlugin. Again, "round-tripping" by switching views back and forth "eat up" the newlines until everything is normalized.

[anonymous]

Looks like a possible subset of this bug occurs consistently, when I have a heading and then I press enter, it generates it seems two [[BR]] tags, rather than a new paragraph. If I try to correct it in the editor it comes out semi-right, but uses [[BR]] to separate a paragraph. To correct it properly I have to go into text mode, fix, then back to the editor.

[Jason Winnebeck]

For some reason the server forgot I was logged in... The above comment was from me (JasonWinnebeck)

[sromanow@…]

I have seen strangeness with this as well. Could we have an option to choose whether newlines should be [[BR]] vs 2 newlines. For our notification emails, all of the markup is included of course. 2 newlines gives nicer output for our use. If this should be another ticket, I apologize.

[Jun Omae]

(In [3847]) fixed #2139 - newline handling problem.

[anonymous]

I tried out this change, and I think my browser reloaded the code (I tried both shift-refresh and ctrl-refresh) -- it's hard to tell what version I'm running, but it still seems to generate weird newlines.

For example, if I have a "properly" formatted Trac page (i.e. just a list of paragraphs with no [[BR]] calls), pressing enter multiple times skips to a new paragraph each time, but sometimes BRs are added, and if I backspace, it seems to make more BRs and sometimes only back up one line rather than a whole paragraph. So I didn't see any affect this changeset had.

If you think this is the problem that you fixed, I can try it again. I've confirmed that I have TracWysiwyg 0.2-r3847 loaded in Trac's admin panel, but I can't be 100% certain that the browser has updated it; is there a way I can tell?

[Jason Winnebeck]

Replying to anonymous:

My apologies for not logging in; that last comment was from me, JasonWinnebeck

[Jun Omae]

Sorry, I mistake. I reopen this ticket.

Do you expect the following converting that keeps empty paragraph?

Source - wysiwyg

<p>start</p>
<p></p>
<p>end</p>

Result - wikitext, including empty lines between start and end

start



end

[Jason Winnebeck]

This is what I mean:

Starting wikitext:

This is a paragraph

In wysiwyg, cursor to end of line, press enter, it skips two lines. Type "This is a second paragraph". Result is:

This is a paragraph

This is a second paragraph[[BR]]

Why the BR? Where does it come from. Second case, start with the original wikitext, then in wysiwyg mode, press enter twice and backspace once. Result is:

This is a paragraph

[[BR]]

Original wikitext, in wysiwyg, press enter twice and backspace twice. You would expect there to be no net result, instead you get:

This is a paragraph

[[BR]]

The second press of the backspace does nothing. Instead I have to press backspace 4 times to reverse the process in wysiwyg mode, although 3 backspaces puts the cursor in the wrong place, but when we convert back to text mode the proper wikitext results. Sometimes backspace will move up one line width (instead of two, <p>-style), and it injects BR as it does so.

One last example, original wiki text, then with cursor at the start of the line and I press enter once and backspace once, it results in:

[[BR]]This is a paragraph

It seems, perhaps, that the root of my problem is that the backspace does not reverse a return, and BRs are put in unnecessarily (IMO), but that sometimes the backspace does reverse a new paragraph. Perhaps this was the intended feature, but then still I would say that the backspace erases sometimes 2 lines, sometimes 1 line. And if 1 line is the intention -- to make it like MS Word, for example -- then the enter key should only move one line, and then any place where

are together are converted into a blank line in wikitext.

[Jun Omae]

Thanks for the detailed report. please try r4135.

[Jason Winnebeck]

Wow, nice! That change fixes all of my cases but the first one. If I start with "This is a paragraph" then pick WYSIWYG mode, then press end to move cursor to end of line, and type <enter>second, then I get as a resulting wiki text:

This is a paragraph

second[[BR]]

My browser is FF 3.0.1

[Jun Omae]

Works for me.... I try the case in comment:10, then I get a wikitext:

This is a paragraph

second

My browser is Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1.

[Jason Winnebeck]

Perhaps my browser did not refresh entirely, because I don't seem to be able to replicate it now at all. I thought maybe the difference between us is something about how we test (I always test by clicking the radio buttons back and forth), except that I can't replicate it again, although I was definitely doing it in the last session.

I suppose from my perspective, this is fixed.