Modify

Opened 7 years ago

Closed 6 years ago

#2139 closed defect (fixed)

Newline handling awkward (at least in FF 2)

Reported by: JasonWinnebeck Owned by: jun66j5
Priority: normal Component: TracWysiwygPlugin
Severity: normal Keywords:
Cc: Trac Release: 0.10

Description

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.

Attachments (0)

Change History (12)

comment:1 Changed 7 years ago by 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.

comment:2 Changed 7 years ago by JasonWinnebeck

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

comment:3 Changed 7 years ago by 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.

comment:4 Changed 6 years ago by jun66j5

  • Resolution set to fixed
  • Status changed from new to closed

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

comment:5 follow-up: Changed 6 years ago by 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?

comment:6 in reply to: ↑ 5 Changed 6 years ago by JasonWinnebeck

Replying to anonymous:

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

comment:7 Changed 6 years ago by jun66j5

  • Resolution fixed deleted
  • Status changed from closed to reopened

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

comment:8 Changed 6 years ago by JasonWinnebeck

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.

comment:9 Changed 6 years ago by jun66j5

Thanks for the detailed report. please try r4135.

comment:10 follow-up: Changed 6 years ago by JasonWinnebeck

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

comment:11 in reply to: ↑ 10 Changed 6 years ago by jun66j5

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.

comment:12 Changed 6 years ago by JasonWinnebeck

  • Resolution set to fixed
  • Status changed from reopened to closed

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.

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.