Opened 12 years ago

Closed 12 years ago

#9857 closed Bug (expired)

Extra space added before closing tag

Reported by: Ryan Owned by:
Priority: Normal Milestone:
Component: General Version: 3.6.4
Keywords: Cc:

Description

I am seeing an extra space that appears before the closing tag of some of the elements. If I submit with those extra spaces, they appear on the site as a black diamond with a white '?' inside it (appears in Chrome 23, Firefox 17, IE 9). The weird thing is that the space only appears inside specific DIV tags.

I can delete the space, and submit those changes and the display is good. However, if I delete the space then switch to the WYSIWYG editor and back to the source view the space reappears.

I found the following link and followed it putting "false" in all the fields, and that removed all the indentation, but the space was still there. http://stackoverflow.com/questions/2547090/removing-unwanted-newline-characters-when-adding-p-in-ckeditor/7045742#7045742

Attachments (1)

black diamond.png (5.0 KB) - added by Ryan 12 years ago.
Black diamond

Download all attachments as: .zip

Change History (11)

comment:1 Changed 12 years ago by Jakub Ś

Status: newpending
  1. Any chance for providing, reduced and working test-case file that shows this problem? Please note that I'm talking about plain sample HTML file that needs only editor freshly downloaded from out site with no custom plugins or add-ons or changes in core. Can you provide such sample?
  1. I have never seen any weird spaces in plain editor. Could you perhaps provide3 a screenshot or screencast that shows this weird space?
  1. They appear on the site as a black diamond with a white '?' - looks a little bit like encoding issue. Have you got utf-8 everywhere - DB, app. page?
  1. Does same problems occur in latest 3.x stable editor 3.6.5 or with 4.0?

Could you all of these questions?

Changed 12 years ago by Ryan

Attachment: black diamond.png added

Black diamond

comment:2 Changed 12 years ago by Ryan

<div class="fb-like" data-href="http://www.example.com/article/article.html" data-layout="button_count" data-send="false" data-show-faces="false" data-width="75"> </div>


Here is a code block that has the problem space. It is the one that appears within the "fb-like" div. And as you see, it's not really a "weird" space...in the plain editor is just shows up as a normal space character so you don't see that you need to delete it, but when the page renders it show the black diamond.

I have attached a screenshot of the black diamond.

Most of the pages are declared ISO-8859-1 (I think) encoding. And the page where this is appearing there is not defined encoding used, so whatever the default is. Another thing is that we are currently use HTML 4.01 Transitional. Not in a position to change that at this moment. I could test defining UTF-8 on this page and see if that helps any.

I can't do anything about changing the version of CKEditor.

Last edited 12 years ago by Ryan (previous) (diff)

comment:3 Changed 12 years ago by Ryan

My mistake...just checked the page and it is encoded with UTF-8.

comment:4 Changed 12 years ago by Jakub Ś

Submitting page, and then displaying it with weird characters has rather nothing to do with CKEditor but with your application in general.

I could test defining UTF-8

Please make sure that your application (E.g. strems that are reading incoming data), DB and HTML pages are all using the same encoding. Best if it is UTF-8 but if you and your users don't use any non-latin characters then ISO could do.


One final test. Could you check your code with ckeditor/ajax.html sample (In editor freshly downloaded from our page)?

Just paste your code there, remove and create editor. This is something like submit test but without any submit or application logic. If you get diamonds there it means that editor is broken (and it would be best if you could provide exact code that is causing this) if not you should look problem in your app.

Could you check and reply?

comment:5 in reply to:  4 Changed 12 years ago by Ryan

Replying to j.swiderski:

Submitting page, and then displaying it with weird characters has rather nothing to do with CKEditor but with your application in general.


What do you mean? Like I said initially, I copy the exact code block into the plain text editor, switch over to the HTML editor, and if I go back to the plain text the problem space character is there. This is before submitting the page. And if I submit with this space in the editor then I will get the black diamond. If on the other hand I copy the code block, and then before submitting I make sure that the space is not there and submit (while still on the plain editor), I will not have the black diamond. So my point was that if I go back and forth between the plain text and HTML editors the space keeps reappearing and I have to delete it every time otherwise, I'll have the black diamond.

I could test defining UTF-8

Please make sure that your application (E.g. strems that are reading incoming data), DB and HTML pages are all using the same encoding. Best if it is UTF-8 but if you and your users don't use any non-latin characters then ISO could do.


If I submit the page without the space, then retrieve it from the database, the space isn't there, until I switch to the plain text editor.


One final test. Could you check your code with ckeditor/ajax.html sample (In editor freshly downloaded from our page)?

Just paste your code there, remove and create editor. This is something like submit test but without any submit or application logic. If you get diamonds there it means that editor is broken (and it would be best if you could provide exact code that is causing this) if not you should look problem in your app.


I downloaded another copy of 3.6.4 and 4.0 and copied that code block into the source editor. For both, if I didn't put anything else into the editor, it would erase the code, so that I went back to the source editor it was empty. If I did put something else like

This is a test
<div class="fb-like" data-href="http://www.example.com/article/article.html" data-layout="button_count" data-send="false" data-show-faces="false" data-width="75"> </div>
still a test...

BECOMES when switching between editors.

<p>
	This is a test</p>
<div class="fb-like" data-href="http://www.techforless.com/article/Refurbished_Laptops_Buying_Guide.html" data-layout="button_count" data-send="false" data-show-faces="false" data-width="75">
	&nbsp;</div>
<p>
	still a test...</p>

It seems to convert the space to a '&nbsp;', which I guess is ok, because the problem I was running into was that it was putting a space there when one didn't exist in the first place. So if there is not a space there to begin with it shouldn't add the '&nbsp;'. I can post a copy of my config.js file if you think that would help.

comment:6 Changed 12 years ago by Jakub Ś

For both, if I didn't put anything else into the editor, it would erase the code

I should start with what you have noticed. I didn’t get this result with space but the one with erasing. Maybe it was some custom change consequence?

What do you mean? Like I said initially, I copy the exact code block into the plain text editor, switch over to the HTML editor, and if I go back to the plain text the problem space character is there. This is before submitting the page.

The whole problem is that such space should not cause any problems and it should not be changed definitely into diamond character.

I remember having similar issue once - #8704.

  1. Crucial thing was to make sure that encoding was consistent in all parts of application
  2. I have also asked - "perhaps you are encoding but not decoding your request parameters." and user admitted that "To store the text into the DB I use a JavaScript function with makes an ajax POST request to a php". This was a jump start. Perhaps it will help you too.

comment:7 Changed 12 years ago by Jakub Ś

@ryan.prather have you managed to fix your issue?

comment:8 in reply to:  6 Changed 12 years ago by Ryan

Replying to j.swiderski:

For both, if I didn't put anything else into the editor, it would erase the code

I should start with what you have noticed. I didn’t get this result with space but the one with erasing. Maybe it was some custom change consequence?

I didn't make any changes to the page, kept it exactly like it was, just added the JS from the page.

What do you mean? Like I said initially, I copy the exact code block into the plain text editor, switch over to the HTML editor, and if I go back to the plain text the problem space character is there. This is before submitting the page.

The whole problem is that such space should not cause any problems and it should not be changed definitely into diamond character.

I remember having similar issue once - #8704.

  1. Crucial thing was to make sure that encoding was consistent in all parts of application
  2. I have also asked - "perhaps you are encoding but not decoding your request parameters." and user admitted that "To store the text into the DB I use a JavaScript function with makes an ajax POST request to a php". This was a jump start. Perhaps it will help you too.

Looks like I just might need to upgrade to 4.0 or something as this just doesn't seem to be consistent across our two systems.

comment:9 Changed 12 years ago by Jakub Ś

I didn't make any changes to the page, kept it exactly like it was, just added the JS from the page.

But you have admitted that different download of same version of editor erased the tag. I have this behaviour in all versions you have mentioned thus someone probably has changed something in CKEditor code.

Looks like I just might need to upgrade to 4.0 or something as this just doesn't seem to be consistent across our two systems.

I would rather suggest fixing errors in your application first and then upgrading to CKE 4.x.
Please note that this is not editor error but error in your application (I'm rather 100% sure). Are you by any chance using the same mechanism as the one described in #8704?

comment:10 Changed 12 years ago by Jakub Ś

Resolution: expired
Status: pendingclosed
Note: See TracTickets for help on using tickets.
© 2003 – 2022, CKSource sp. z o.o. sp.k. All rights reserved. | Terms of use | Privacy policy