Bug #32263
closed
HTML entity is inserted before and after HTML Tags
100%
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</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
Updated by Björn Pedersen almost 13 years ago
- Project changed from 1947 to TYPO3 Core
Moved from Incubator to core.
Updated by Xavier Perseguers almost 13 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.
Updated by Dieter Bunkerd almost 13 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
Updated by Martin Holtz almost 13 years ago
please change TYPO3 Version to 4.5, which is affected too.
Updated by Jan Loderhose almost 13 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.
Updated by Chris topher almost 13 years ago
- Category set to RTE (rtehtmlarea + ckeditor)
Updated by Christian Buelter almost 13 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>
Updated by Christian Lerrahn almost 13 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. :(
Updated by Mario Rimann almost 13 years ago
Problem confirmed with 4.5.10 - please change "affected version" of this issue from 4.7 to 4.5.x
Updated by Steffen Gebert almost 13 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.. :-(
Updated by Christian Lerrahn almost 13 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.
Updated by Stanislas Rolland almost 13 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.
Updated by Gerrit Code Review almost 13 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
Updated by Gerrit Code Review almost 13 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
Updated by Stanislas Rolland almost 13 years ago
- Status changed from Under Review to Resolved
Updated by Gerrit Code Review almost 13 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
Updated by Stanislas Rolland almost 13 years ago
- Status changed from Under Review to Resolved
- % Done changed from 0 to 100
Applied in changeset 02d465fe03d3e76f366278b4f814ee547dece8b1.
Updated by Stephan Vidar almost 13 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 ‹a href=''›..‹/a › String"
Updated by Mario Rimann almost 13 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.
Updated by Stanislas Rolland almost 13 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 ‹a href=''›..‹/a › String"
You should clear the RTE cache after applying the patch.
Updated by Stephan Vidar almost 13 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...
Updated by Stanislas Rolland almost 13 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.
Updated by Stephan Vidar almost 13 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!
Updated by Stanislas Rolland almost 13 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!
Updated by Riccardo De Contardi about 7 years ago
- Status changed from Resolved to Closed