Bug #32263

HTML entity   is inserted before and after HTML Tags

Added by Dieter Bunkerd over 9 years ago. Updated over 3 years ago.

Status:
Closed
Priority:
Must have
Category:
RTE (rtehtmlarea + ckeditor)
Target version:
Start date:
2011-12-02
Due date:
% Done:

100%

Estimated time:
TYPO3 Version:
4.5
PHP Version:
5.3
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

If an editor marks text for making it bold, italic and so on,
typo3/sysext/rtehtmlarea/htmlarea/htmlarea.js
adds non breakable spaces before and after each HTML tag. An editor is unable to delete them again, not even in HMTL mode.

Editing the file (from line 2235)

return this.textArea.getValue().
replace(/[\x20]+/g, '\x20').
replace(/^\x20/g, ' ').
replace(/\x20$/g, ' ');
// replace(/>\x20/g, '> ').
// replace(/\x20&lt;/g, '&nbsp;<');

saves the problem. But what are these two replacements meant to do anyway?

TYPO3 4.6.1
htmlarea version 2.2.1

also present in
TYPO3 4.5.8
htmlarea version 2.1.7


Related issues

Related to TYPO3 Core - Bug #61747: Depending on how we delete something in RTE, we get different results after savingClosedStanislas Rolland2014-09-19

Actions
Has duplicate TYPO3 Core - Bug #33170: RTE chaotic &nbsp; spreadingClosed2012-01-13

Actions
Has duplicate TYPO3 Core - Bug #31579: Copied MS Word content becomes broken after saving and opening text content elementClosedStanislas Rolland2011-11-04

Actions
Follows TYPO3 Core - Bug #16217: Leading and trailing blanks can't be editedClosedStanislas Rolland2006-06-06

Actions
#1

Updated by Björn Pedersen over 9 years ago

  • Project changed from 1947 to TYPO3 Core

Moved from Incubator to core.

#2

Updated by Xavier Perseguers over 9 years ago

  • Status changed from New to Needs Feedback
  • TYPO3 Version set to 4.7

I remember when this part was changed. So here is what I did to understand why it was changed (for your point of view):

With Tower (GUI for Git), I selected the htmlarea.js file and "blamed" it, this showed that the whole 'textmode' cas block had been changed by Stanislas on 2nd September 2011. This is part of the commit with hash 5e37e10267 and thus the corresponding bug entry is #16217.

Please check with what was done there.

#3

Updated by Dieter Bunkerd over 9 years ago

Well, unfortunately I don't have time to dig any deeper in this issue right now.

What JS does here, is to replace every space followed by '<' with &_nbsp; and any space preceeded by '>' with &_nbsp; also. I think this is definately not what we need or want.

Do I get it right that a patch form 2008-10-04 05:54 related to a bug form 2006-06-06 made it to the core on 2nd September 2011? The suggested patch in #16217 was a change to t3lib_parsehtml_proc::TS_transform_db in class.t3lib_parsehtml_proc.php ...

Best regards

#4

Updated by Martin Holtz over 9 years ago

please change TYPO3 Version to 4.5, which is affected too.

#5

Updated by Jan Loderhose over 9 years ago

Could someone set the category to rtehtmlarea, please? It needs a good deal of luck to discover that the issue is already processed. Thanks to the friendly ghost.

#6

Updated by Chris topher over 9 years ago

  • Category set to RTE (rtehtmlarea + ckeditor)
#7

Updated by Christian Buelter over 9 years ago

I can confirm the behaviour for version 4.5.10.

Example:

<p>Porttitor etiam porttitor sed a ultricies, aenean urna!</p>

is transformed to

<p>Porttitor etiam <span style="font-weight: bold;">porttitor</span> sed a ultricies, aenean urna!</p>

After marking the word "porttitor" as bold AND SAVING the text element.

If I only mark the word as bold and do not save the text element, the markup is correct:

<p>Porttitor etiam <span style="font-weight: bold;">porttitor</span> sed a ultricies, aenean urna!</p>

If I mark the word and the following space character, the transformation is done like this, the space is getting transformed to a non-breaking-space, I don't think that's right, is it?:

<p>Porttitor etiam <span style="font-weight: bold;">porttitor</span> sed a ultricies, aenean urna!</p>

#8

Updated by Christian Lerrahn over 9 years ago

Any progress on this one? I have to deal with rather cranky editors that complain that their pages are getting all messed up and can't tell them anything.

And, the longer this is lingering the more need for repair there will be once it's fixed. :(

#9

Updated by Mario Rimann over 9 years ago

Problem confirmed with 4.5.10 - please change "affected version" of this issue from 4.7 to 4.5.x

#10

Updated by Steffen Gebert over 9 years ago

  • TYPO3 Version changed from 4.7 to 4.5

Stan, what's the status of this issue? It looks like it bothers a lot of users.. :-(

#11

Updated by Christian Lerrahn over 9 years ago

I think it would be best to revert the bugfix that led to this problem until a better solution exists.
IMHO, the bugfix does more harm than the bug it fixes.

#12

Updated by Stanislas Rolland over 9 years ago

  • Assignee set to Stanislas Rolland
  • Target version set to 4.5.11
  • PHP Version set to 5.3

The problem arises as a result of the fix to issue #16217.

The replacement of leading and trailing spaces with non-breaking spaces is wrong and should apply only to block elements.

#13

Updated by Gerrit Code Review over 9 years ago

  • Status changed from Needs Feedback to Under Review

Patch set 1 for branch TYPO3_4-6 has been pushed to the review server.
It is available at http://review.typo3.org/7753

#14

Updated by Gerrit Code Review over 9 years ago

Patch set 1 for branch TYPO3_4-5 has been pushed to the review server.
It is available at http://review.typo3.org/7754

#15

Updated by Stanislas Rolland over 9 years ago

  • Status changed from Under Review to Resolved
#16

Updated by Gerrit Code Review over 9 years ago

  • Status changed from Resolved to Under Review

Patch set 1 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/7838

#17

Updated by Stanislas Rolland over 9 years ago

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

Updated by Stephan Vidar over 9 years ago

Patch doesn't work in TYPO3 4.5.8 / TYPO3 4.5.10. The effect is still the same if you toogle the html/text-mode:

"String ‹a href=''›..‹/a › String" is converted into "String&nbsp;‹a href=''›..‹/a ›&nbsp;String"

#19

Updated by Mario Rimann over 9 years ago

@Stephan: Since this issue has been closed already, it might be that it won't show up on the radar of the developer(s). Please file a separate bug report with detailed information, which refers to this one.

#20

Updated by Stanislas Rolland over 9 years ago

Stephan Vidar wrote:

Patch doesn't work in TYPO3 4.5.8 / TYPO3 4.5.10. The effect is still the same if you toogle the html/text-mode:

"String ‹a href=''›..‹/a › String" is converted into "String&nbsp;‹a href=''›..‹/a ›&nbsp;String"

You should clear the RTE cache after applying the patch.

#21

Updated by Stephan Vidar over 9 years ago

Stanislas Rolland wrote:

You should clear the RTE cache after applying the patch.

After including the patch, I've emptied the RTE cache, Browser cache and tested the backend in different browsers...

#22

Updated by Stanislas Rolland over 9 years ago

Stephan Vidar wrote:

After including the patch, I've emptied the RTE cache, Browser cache and tested the backend in different browsers...

I am unable to reproduce this behaviour with the patch applied.

#23

Updated by Stephan Vidar about 9 years ago

Sorry, now I can confirm - it works!!! To empty RTE cache, I have used "Clear all caches", but this doesn't imply emptying RTE cache. Is it a bug or a feature? After I've emptied explicitly RTE cache, the patch works fine... Sorry again for your wasted time!

#24

Updated by Stanislas Rolland about 9 years ago

Stephan Vidar wrote:

Sorry, now I can confirm - it works!!! To empty RTE cache, I have used "Clear all caches", but this doesn't imply emptying RTE cache. Is it a bug or a feature?

Well... Emptying the RTE cache is an admin/dev action, so I don't know if this is really a bug.

After I've emptied explicitly RTE cache, the patch works fine... Sorry again for your wasted time!

No problem. Happy to know that this is indeed fixed!

#25

Updated by Riccardo De Contardi over 3 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF