Item1899: Spaces at end-of-line

If you have the following text:

das ist eine zeile

und das noch eine

(note: there are no spaces at end-of-line)

then, editing with TinyMCE, you can have some fun:

Editing with TinyMCE, browser Internet Explorer 6

There seems to be a space at end-of-line. That is confusing from time to time, but this space is deletable. After saving (as before saving), a space is rendered each line in the view (marking the text you will see this). Also the raw view shows this spaces. Raw edit demonstrates: no spaces. TinyMCE edit: spaces again. If you write after the space and save, there is a space (but no one have ever entered it in the text!).

Editing with TinyMCE, browser Firefox 3.0.11

There is no space in the view. Editing, there seems to be a space at the end-of-line and you can use the cursor keys to get at the end-of-line and back to the end of the last word. But if you use the Backspace/Delete-Key, the last letter of the line is gone. If you position the cursor after the space and append a few words, the space disappears. After saving, there is no space observable.

Conclusions

It is very clear that the differences in rendering are depending on various factors - here it seems to be the mechanism of the browsers to display UTF-8 linefeed (Did I forget to explicitely mention this?). What is really irritating is that this spaces are there at editing, but only "useable" with Internet Explorer, in Firefox they are only there to fool you. I hate it

In both browsers the displaymode/coding is shown as UTF-8. The data is stored on the server with UTF-8. The other parameters are: Foswiki-1.0.6, Sun, 21 Jun 2009, build 4272, RHEL 5, TinyMCEPlugin (03 Jul 2009, $Rev: 4429 (2009-07-03) $), WysiwygPlugin (28 Jun 2009, $Rev: 4429 (2009-07-03) $).

-- WolfgangRaus - 07 Aug 2009

Confirmed. Suggestions welcome

-- MichaelTempest - 08 Aug 2009

I just checked this.

If I have a bullet and the text after ends with no trailing white space.

And I edit and save in IE6.

There is a space added after the bullet.

We had this bug before and the result was MAJOR MAJOR problem for people as MANY settings ( * Set Something = value) are goofed if you add a space after the value.

We had so many issues with this that there is no way a 1.0.7 is released with this which means either we fix it - or 1.0.7 is with old TMCE.

Same with 1.1. No release of 1.1 until this is fixed.

Note that we cannot just remove trailing spaces. If someone keys a space or it is already there is must stay.

We could live with trailing spaces many places but not in bullets.

PS: Do not put random text in the Component field. Otherwise the Urgent bugs are not listed.

-- KennethLavrsen - 08 Sep 2009

It is strange with this bug.

In IE 6 you see the spaces at the end but they are not saved. That makes that less urgent. The issue is when people edit a preference topic and save it and all preferences are goofed.

But in IE8 the TMCE now adds a space after a bullet IF the following bullet is indented. Very odd. I think we need to extend the special handling of trailing spaces to also take care of this.

-- KennethLavrsen - 13 Sep 2009

Lowering to Normal

-- KennethLavrsen - 16 Sep 2009

These cursor positioning problems are maddening. Confirmed firefox behaviour as already noted by MichaelTempest continues with force_root_blocks: false removed.

-- PaulHarvey - 16 Jan 2010

As of 1.1.3beta1, it appears that the extra newlines are tamed. They still appear in the editor, but seem to be correctly swallowed or preserved when writing the topic back out. Adding a space in Wysiwyg on IE6, IE7, Firefox and Chrome 9 all work fine. If a space is not intentionally added, the apparent extra spaces in the gui are not saved to the topic. So this all looks reasonably fixed. Changing to No action Required.

-- GeorgeClark - 13 Mar 2011