Bug #16217: Leading and trailing blanks can't be edited - TYPO3 Core - TYPO3 Forge

Actions

Copy link

Bug #16217

closed

Leading and trailing blanks can't be edited

Added by Ralf Hettinger almost 18 years ago. Updated almost 9 years ago.

Status:

Closed

Priority:

Should have

Assignee:

Stanislas Rolland

Category:

RTE (rtehtmlarea + ckeditor)

Target version:

Start date:

2006-06-06

Due date:

% Done:

100%

Estimated time:

TYPO3 Version:

4.5

PHP Version:

Tags:

Complexity:

Is Regression:

Sprint Focus:

Description

I will explain this issue by an example:

Following input ([blank] stands for a blank)

[blank]test[blank]

to an RTE field inserted and saved with "RTE disabled" or pasted into an htmlarea powered RTE field will render to the following HTML code inside the textarea tags delivered by htmlarea:

[blank]test[blank]

The two blanks are still there but can't be properly edited when the RTE is enabled (why?):
In IE, they are partially removed after saving (generally spoken, leading blanks seem to be removed somewhere, trailing blanks seem to be editable).
In Firefox, all leading and trailing blanks are still there after saving and never editable.

Under certain circumstances (eg if sorting in the backend is triggered by a RTE field and editors are supposed to always use the RTE and copy and paste from the outside world) this can be pretty bothering.

Suggestion for resolving the issue:

One possible fix would be to assure a consistent behaviour and trim all leading and trailing white-space from rte->db. That approach might not be acceptable for all circumstances although at this time, I can't imagine why one would like to have leading or trailing white-space in an RTE field which afterwards isn't properly editable anyways.

The suggested behaviour could be simply achieved by patching the core... hm... I'm fine with that and it's just a suggestion.

t3lib_parsehtml_proc::TS_transform_db in class.t3lib_parsehtml_proc.php

}
$this->TS_transform_db_safecounter++;

return implode('',$blockSplit);
}

---
< }
< $this->TS_transform_db_safecounter++;
<
< return trim(implode('',$blockSplit));
< }
(issue imported from #M3632)

Files

Download all files

rtehtmlarea_bugfix_3632_trunk.patch (768 Bytes) rtehtmlarea_bugfix_3632_trunk.patch		Administrator Admin, 2008-10-04 05:54
rtehtmlarea_bugfix_3632_typo3_4-2.patch (768 Bytes) rtehtmlarea_bugfix_3632_typo3_4-2.patch		Administrator Admin, 2008-10-04 05:54

Related issues 1 (0 open — 1 closed)

Actions

Copy link

Updated by Ralf Hettinger almost 18 years ago

just correcting a typo in the description
"
[...] will render to the following HTML code inside the textarea tags delivered by htmlarea:

[blank]test[blank]
[...]
"

Actions

Copy link

Updated by Stanislas Rolland over 15 years ago

I cannot reproduce this behaviour with latest trunk in Firefox3 nor in IE7. Do you still encounter this issue?

Actions

Copy link

Updated by Xavier Perseguers over 15 years ago

I can reproduce this bug:

- Create a new textblock
- switch to source code
- type [blank]test[blank]
- switch back to RTE
- save
- leading space is not editable, trailing space can be edited/deleted
- Rendered to FE as [blank]test[blank] (with or without additional stuff in p according to the RTE config

I did it with FF3 and 4.2.1 + trunk

Actions

Copy link

Updated by Stanislas Rolland over 15 years ago

Thanks. Now I understand how to reproduce.

Actions

Copy link

Updated by Stanislas Rolland over 15 years ago

The problem also exists if you add leading and trailing spaces inside a paragraph in text mode. In FF, the leading space remains there but is not editable. IE removes it. In IE, the trailing space is editable, not in FF.

I note that IE collapses any repeating such spaces into a single one. In FF, if you insert a sequence of repeating spaces in the middle of a word in text mode, they are shown as one in wysiwyg mode, but they are still there.

Safari, Chrome and Opera all behave like Firefox.

Actions

Copy link

Updated by Stanislas Rolland over 15 years ago

The attached patches (one for trunk, the other for TYPO3 4.2 branch) will:

1. collapse repeating spaces into a single one;
2. replace leading and trailing spaces with non-breaking spaces.
3. replace any space following > and any space preceding < by a non-breaking space.

Please comment and test.

Actions

Copy link