Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#8911 closed Bug (duplicate)

pasting text seems inconsistent

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

Description

Pasting text seems to differ in how the editor wraps it in html based on where you copy it from. Best guess is this has to do with new line delimiters breaking some sort of state machine.

For example if we pasted these 3 lines: # Changes not staged for commit: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory)

We would hope to get something like this with p tags (with more markup): <p># Changes not staged for commit:</p> <p># (use "git add <file>..." to update what will be committed)</p> <p># (use "git checkout -- <file>..." to discard changes in working directory)</p>

but in reality we get this: <p>

&nbsp;</p>

<div>

# Changes not staged for commit:</div>

<div>

# &nbsp; (use &quot;git add &lt;file&gt;...&quot; to update what will be committed)</div>

<div>

# &nbsp; (use &quot;git checkout -- &lt;file&gt;...&quot; to discard changes in working directory)</div>

<div>

&nbsp;</div>

But other times we do get the p tags correctly. Furthermore, as this screenshot shows it seems to incorrectly believe the nesting level is different from the markup it produces (and for what its worth the dom shows that as well).

https://skitch.com/jeffreybasurto/8w1x6/demo-ckeditor

but after clicking source and coming back the nesting state changes without any changes to the text.

https://skitch.com/jeffreybasurto/8w1tf/demo-ckeditor

Our best guess is that the problem occurs when the clipboard contains \r\n rather than plain \n since the problem doesn't happen from many sources.

Attachments (1)

screen.png (59.8 KB) - added by Jakub Ś 6 years ago.

Download all attachments as: .zip

Change History (13)

comment:1 Changed 6 years ago by Jakub Ś

  1. Where do you past those lines from - notepad?
  2. In which browser are you getting divs - Chrome/Safari?
  3. What enterMode in set for you CKEditor?

comment:2 in reply to:  1 Changed 6 years ago by jeffreybasurto

Replying to j.swiderski:

  1. Where do you past those lines from - notepad?
  2. In which browser are you getting divs - Chrome/Safari?
  3. What enterMode in set for you CKEditor?
  1. They were pasted from OSX terminal, but the problem happens from other sources including notepad in windows. However, it does not happen in OSX TextEdit, or Mail app, or some other sources.
  1. Every browser we've tested is consistent in this problem. Chrome, firefox, and IE.
  1. We tested it with with different enter modes, but where I've reproduced the problem for illustration for this ticket has been on the official demo of ckeditor itself.

If you need more information please let me know. We're eager to get a fix for this ASAP.

comment:3 Changed 6 years ago by Jakub Ś

Resolution: duplicate
Status: newclosed

They were pasted from OSX terminal, but the problem happens from other sources including notepad in windows.

That is what I was afraid of. This is unfortunately a won't fix and a duplicate of #7622 (Please see comment two for details).

comment:4 Changed 6 years ago by jeffreybasurto

This ticket should not be closed. We don't believe that this is a duplicate of the bug linked to. If this issue is unclear to you we're glad to provide you with more information, screens, screencasts, whatever you need. There two reasons this is clearly a bug on your end and doesn't match with the ticket you linked:

  1. This happens in all browsers, including chrome and firefox. It's consistently the same problem.
  2. The nested level your software reports is not actually the nested level when you click view source. This at face value is a different bug, and we believe is related to the problem.

It's our suspicion that your software is not robustly handling all possible line feed sequences correctly. For example: \n, \r\n, \n\0, etc.

One last thing worth mentioning: We're commercial level users. Your competitors don't have this same issue. If it's a browser bug why are they able to paste content correctly but you aren't? Needless to say we're potentially looking at other options.

Last edited 6 years ago by jeffreybasurto (previous) (diff)

comment:5 Changed 6 years ago by Jakub Ś

Your competitors don't have this same issue. If it's a browser bug why are they able to paste content correctly but you aren't?

This is not a browser bug but how browsers work. I have never said it’s a browser bug.

Please read the comment from #7622 once more:

The editor receives "post-processed" data, where BRs, DIVs or Ps are already in place. We cannot normalize the data at that point, because we are not able to understand what exactly the source data looked like.

The fact that browser gets to pasted data first is undeniable. What this other editor does is processing data after it was processed by a browser. They process it while we leave it untouched.

The fact that this works in simple example does not mean that it will not break the formatting in other.

NOTE: We are getting ready to introduce RC for version 4 of the editor which will be free of this bug.


About element's path - well it shows elements correctly. If you will have a look at Screen.png you will notice that when examining code with developer tools divs are actually nested inside paragraph. This gets fixed when switching to source or getting the data from editor (when HTML data processor is called). That is why users get impression that extra p is added.

This particular problem was described here: #6131 (#7622 is a DUP of #6131). Other related problems are here: #7146 and #8231.

NOTE: Again all this will be fixed in version 4 of editor which will soon be introduced.

Changed 6 years ago by Jakub Ś

Attachment: screen.png added

comment:6 Changed 6 years ago by jeffreybasurto

"We are getting ready to introduce RC for version 4 of the editor which will be free of this bug."

How long could we expect that to take as a rough estimate? And if it's out of your control now why is it a new version of the editor fixes, your words, this bug?

comment:7 Changed 6 years ago by Jakub Ś

How long could we expect that to take as a rough estimate?

Shortcut for RC is "Release Candidate" - as the name implies users will be testing it, reporting their findings and we will be fixing bugs - this will definitely not take a week.


And if it's out of your control now why is it a new version of the editor fixes, your words, this bug?

Excuse me, I don't mean to be rude but do you even read what I write!? I have written:

processing data after it was processed by a browser. They process it while we leave it untouched.

What means that in v3 we don't touch code processed by a browser but we will be post-processing it in v4. In v3 we have taken different approach which we want now to improve.


Needless to say we're potentially looking at other options.

If you are in a hurry than there is no sense in waiting for v4. All I can say that if you want to see something completely new, please come back in some time.

comment:8 Changed 6 years ago by jeffreybasurto

This is some pretty ridiculous treatment we're getting as commercial customers getting ready to pull the trigger on your software.

You said: "NOTE: We are getting ready to introduce RC for version 4 of the editor which will be free of this bug."

So yes, excuse me, I have read what you've replied. And it's a bunch of CYA nonsense. We've spent a lot of time and effort (read: money) investigating this issue that none of your competitors have, and you can't even give me a coherent reason why the version of the software you're asking $1450 dollars for has no consistent paste text function? You're not offering any solution to 3.0 users except deal with it the random markup it's generating? That's a basic function of a text editor. Are you kidding me?

Wow. I've had some shitty support before, but this takes the cake. Really? You'd rather just turn away money than give us some type of estimate? I can tell you this much, I'm just a cog in the machinery here so ultimately I may have no choice, but if I ever have the option I'll never again even consider this product, or anything else your company has touched. And you can be damn sure I'm going to spread the word.

comment:9 Changed 6 years ago by Jakub Ś

ridiculous treatment we're getting as commercial customers
I've had some ***** support before

  • First of all this is open bug tracker for reporting bugs and not support channel. You have used wrong communication channel. How was I suppose to even know that you are commercial customer?
  • Second, so you have reported a bug because you don't like how CKEditor works and because it won't get changed you suddenly hate all our products. No comments here.
  • Third I have made mistake in my previous posts using the word bug. This is not a bug but how CKEditor currently works, end of story. We will take different approach in v4 of the editor. To change this behavior we would have change a lot of core code in the editor and since new version will be released soon we have decided to leave it the way it it in v3.

And you can be damn sure I'm going to spread the word.

Go ahead and don't forget to attach link to this post. Hmm, user suddenly hating company because he didn't like how editor worked by default and furthermore ignoring the fact that we, knowing that this is not what users expect, have decided to introduce this in next major release. Yes, shame on us :)

I will repeat it one more time the only reason why we will not introduce this in current version is that it requires major changes in core code and new version will be released soon.

comment:10 Changed 6 years ago by Jakub Ś

That's a basic function of a text editor.

Actually most users paste text from word or paste HTML. Pasting from notepad is not that common.

You're not offering any solution to 3.0 users except deal with it the random markup it's generating?

For the third time - browser is generating this random markup and CKEditor does not touch this processed code.
I'm not just saying deal with it. In current version it would be very hard to change this behavior (we have definitely spent more time and effort investigating it – so this is not CYA excuse) but when designing v4 we have taken this issue into account. What I'm saying is that I hope that all users who don't like this behavior will upgrade from v3 to v4.

Sorry for not having ready to use solution for your problem.

comment:11 Changed 6 years ago by jeffreybasurto

My sincere apologies for getting irritated and a little short with you. We love your software and the work you've done on CKeditor. Especially coming from one of your competitors, the transition has been relatively pain free. It's just a little frustrating from our perspective. So I hope as a fellow developer you'll understand that it's nothing personal and give a little latitude here. I really appreciate you taking the time to explain so fully and professionally the problem from your end. It's helpful to know that this will be addressed in version 4. Please keep up the good work. We're big fans and we would really like to be part of the beta testers for this software as soon as it's available. Could you give any information on how we may be part of that?

comment:12 Changed 6 years ago by Jakub Ś

I'm sorry too for getting irritated - I wish we had answers/patches for all the problems but this is just not possible.

Could you give any information on how we may be part of that?

You don't need to sign in anywhere, v4 will be available on our site to everyone just like it was in case of v3 (http://ckeditor.com/blog/CKEditor_3.0_Beta_released).

Last edited 6 years ago by Jakub Ś (previous) (diff)
Note: See TracTickets for help on using tickets.
© 2003 – 2017 CKSource – Frederico Knabben. All rights reserved. | Terms of use | Privacy policy