Project

General

Profile

Actions

Bug #16217

closed

Leading and trailing blanks can't be edited

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

Status:
Closed
Priority:
Should have
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:
No
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:

<p>[blank]test[blank]</p>

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


Related issues 1 (0 open1 closed)

Precedes TYPO3 Core - Bug #32263: HTML entity &nbsp; is inserted before and after HTML TagsClosedStanislas Rolland2011-12-02

Actions
Actions #1

Updated by Ralf Hettinger over 18 years ago

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

<p>[blank]test[blank]</p>
[...]
"

Actions #2

Updated by Stanislas Rolland about 16 years ago

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

Actions #3

Updated by Xavier Perseguers about 16 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 <p>[blank]test[blank]</p> (with or without additional stuff in p according to the RTE config

I did it with FF3 and 4.2.1 + trunk

Actions #4

Updated by Stanislas Rolland about 16 years ago

Thanks. Now I understand how to reproduce.

Actions #5

Updated by Stanislas Rolland about 16 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 #6

Updated by Stanislas Rolland about 16 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 #7

Updated by Ralf Hettinger about 15 years ago

Looking good to me. Thank you.

Actions #8

Updated by Andreas Wolf over 13 years ago

  • Assignee set to Stanislas Rolland
  • Target version deleted (0)
  • TYPO3 Version set to 4.0

Hey Stan, is this still relevant?

Actions #9

Updated by Stanislas Rolland over 13 years ago

Andreas Wolf wrote:

Hey Stan, is this still relevant?

Just forgot about that one. Will need to submit patches to gerrit for current releases.

Actions #10

Updated by Mr. Hudson over 13 years ago

Patch set 1 of change I06a8996f23e050e2e30cc2548c9c1bbafd5b41f0 has been pushed to the review server.
It is available at http://review.typo3.org/4758

Actions #11

Updated by Stanislas Rolland over 13 years ago

  • Status changed from Needs Feedback to Under Review
Actions #12

Updated by Mr. Hudson about 13 years ago

Patch set 1 of change I630249ddf143c401706688a10867ddd33493f971 has been pushed to the review server.
It is available at http://review.typo3.org/6258

Actions #13

Updated by Stanislas Rolland about 13 years ago

  • Status changed from Under Review to Resolved
  • % Done changed from 0 to 100
Actions #14

Updated by Stanislas Rolland almost 13 years ago

  • Status changed from Resolved to New
  • TYPO3 Version changed from 4.0 to 4.5

The last two lines of the merged patch are wrong.

They should replace only leading and trailing spaces inside block elements.

Actions #15

Updated by Alexander Opitz almost 10 years ago

  • Status changed from New to Needs Feedback
  • Is Regression set to No

@Stanislas

You reopened this issue. Is the missing part already fixed, so this issue can be closed again?

Actions #16

Updated by Wouter Wolters over 9 years ago

  • Status changed from Needs Feedback to Closed

The mentioned lines are removed in master and 6.2. Will close the issue now.

Actions

Also available in: Atom PDF