Opened 6 years ago

Last modified 3 years ago

#9998 confirmed Bug

In Chrome SPAN tags appear when merging paragraphs with delete/backspace. — at Version 44

Reported by: lmeurs Owned by:
Priority: Normal Milestone:
Component: General Version:
Keywords: Blink Webkit Cc: laura@…, ben@…, matti.jarvinen@…, ivanjh@…, joel.peltonen@…

Description (last modified by Piotrek Koszuliński)

Occurs in Chrome v24.0.1312.56 / CKEditor 4.0.1 (revision d02739b) / CKEditor 4 DEV (Standard) (revision d02739b) (nightly build demo)

Did not occur in Firefox v17.0.1

When you have a paragraph with several lines of text, ie.:

<p>line1<br />
line2</p>

and want to create 2 separate paragraphs, you could go with your cursor to the end of line1, press ENTER to create a new paragraph and press DELETE to remove the whiteline caused by the BR tag. Then CKEditor puts some HTML in a SPAN tag with a line-height styling.

<p>line1</p>
<p><span style="line-height: 1.6em;">line2</span></p>

Other examples: It also happens when trying to create a single line out of the next cases:

<p><br />
line2</p>

and

<p>line1</p>
<p>line2</p>

Edits

  • This happens when two paragraphs are joined with delete. Tag br has nothing to do here.

Content: <h1>^test</h1> + enter + backspace creates awful mess.

Change History (44)

comment:1 Changed 6 years ago by Jakub Ś

Keywords: Chrome added; chrome removed
Status: newconfirmed
Version: 4.0.14.0

Problem can be reproduced from CKEditor 4.0 in Chrome only.

comment:2 Changed 6 years ago by Jakub Ś

Description: modified (diff)
Summary: In Chrome SPAN tags appear when removing BR tagsIn Chrome SPAN tags appear when merging paragraphs with delete.
Last edited 6 years ago by Jakub Ś (previous) (diff)

comment:3 Changed 6 years ago by Jakub Ś

Summary: In Chrome SPAN tags appear when merging paragraphs with delete.In Chrome SPAN tags appear when merging paragraphs with delete/backspace.

#10056 was marked as duplicate.

comment:4 Changed 6 years ago by lollypopstar

Cc: laura@… added

comment:5 Changed 6 years ago by Jakub Ś

#10064 was marked as duplicate.

comment:6 Changed 6 years ago by mandius

Cc: ben@… added

Adding as CC

comment:7 Changed 6 years ago by Piotrek Koszuliński

Description: modified (diff)

comment:8 Changed 6 years ago by Piotrek Koszuliński

Description: modified (diff)
Priority: NormalHigh

I started to feel that we can't rely on Webkit's backspace behaviour any more. Those styling spans are unacceptable thus I'm changing priority to high.

comment:9 Changed 6 years ago by Frederico Caldeira Knabben

To start off, we need a ticket opened at WebKit's side. Considering that this is an annoying browser bug, there is a chance that they'll be interested on having this fixed.

comment:10 Changed 6 years ago by mandius

This appears to be fixed in Chrome 25.0.1364.97 m on Windows!

comment:11 Changed 6 years ago by lmeurs

Unfortunately the problem still occurs on my Chrome 25.0.1364.97 on Windows.

comment:12 Changed 6 years ago by Piotrek Koszuliński

Thanks for info.

We'll take care of this issue as soon as we'll close 4.1 and 4.0.2 releases.

comment:13 Changed 6 years ago by Jakub Ś

#10133 was marked as duplicate.

comment:14 in reply to:  11 Changed 6 years ago by mandius

Replying to lmeurs:

Unfortunately the problem still occurs on my Chrome 25.0.1364.97 on Windows.

Hmmm. I just tried again and you're right, it is still doing it! I got excited because I tested on my site's CKeditor this morning and then in the demo and it didn't do it in either. I've just closed and reopened Chrome and now it's doing it again. WTF? Sorry for the false hope! :(

comment:15 Changed 6 years ago by Roman

Hi guys!

Any updates? Just updated to 4.1, but unfortunately the problem is still exist. Chrome 25.0.1364.172 Hope you be able to fix/help soon.

Thank you!

comment:16 Changed 6 years ago by Piotrek Koszuliński

We're focused on other tasks right now and we won't work on bringing the sanity to how backspace/del works on Chrome at least for few weeks, because this is pretty tough task. In fact, we will first report this issue on Webkit's bug track, to see if this is intentional behaviour or not. I guess that I'll have some time to handle this next week.

comment:17 Changed 6 years ago by Roman

Hi Reinmar,

Thanks for quick response. That's sad, but I still hoping =) I also niticed that new CKEditor 4.1 has new events, toHtml and toDataFormat. Maybe I can filter this bug, could you please point out the right direction to me?

comment:18 Changed 6 years ago by Matti Järvinen

Cc: matti.jarvinen@… added

following cc

comment:19 Changed 6 years ago by ivanjh

Cc: ivanjh@… added

Also affects 26.0.1410.43 (Win & Mac)

comment:20 Changed 6 years ago by Berry

Experiencing the same issue, following cc

comment:21 Changed 6 years ago by Jakub Ś

replying to comment:17 minkinroman@... neither these events nor ACF seem to be any help here.

The only way to get rid of this bug is by implementing custom del/backspace (non-trivial). Another would be fixing this by Chrome.

comment:22 Changed 6 years ago by Chris

Also experiencing on Ubuntu Chromium 25.0.1364.160

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

comment:23 Changed 6 years ago by Piotrek Koszuliński

http://code.google.com/p/chromium/issues/detail?id=226941

I reported this issue on Chromium bug tracker, which is now also used for Blink engine.

Let's see what Chrome developers will say.

comment:24 Changed 6 years ago by ryanissamson

Whew, glad it wasn't just me. Yea - this is happening still - OS X Chromium 26.0.1410.43

comment:25 Changed 6 years ago by jcisio

This is really annoying. I've just pumping on the Chrome issue with detail on a WebKit commit https://trac.webkit.org/changeset/135421.

However, the easiest way to fix it, now, is to remove content.css.

comment:26 Changed 6 years ago by Piotrek Koszuliński

Thanks for your help. I'll report the same ticket on Webkit bugtracker too.

comment:27 Changed 6 years ago by crisward

This seems to fix it for me. Uses a bit of Jquery, but doesn't need it. Not ideal I know, but it works.

var editor = CKEDITOR.inline("editor",options);

$("#editor").on('keyup',function(e){
        if(e.keyCode===8){
          var node=editor.getSelection().getRanges()[0].endContainer.$.nextSibling;
          if (node.tagName === "SPAN"){
            $(node).replaceWith($(node).contents());
          }
        }
});
Last edited 6 years ago by crisward (previous) (diff)

comment:28 Changed 6 years ago by ryanissamson

I removed the content.css file and that fixed the issue. Hopefully it gets sorted soon!

comment:29 Changed 6 years ago by Jakub Ś

@ryanissamson thanks for the tip. It seems if you remove below CSS class with line-height: 1.6em; you don't get this problem anymore.

.cke_editable
{
	font-size: 13px;
	line-height: 1.6em;
}

I have also checked the same in plain contenteditable element without CKEditor. Result is the same. This is definitely Browser Bug.

comment:30 Changed 6 years ago by jcisio

A bug, or maybe a feature, as the link I posted in http://dev.ckeditor.com/ticket/9998#comment:25

comment:31 Changed 6 years ago by Matti Järvinen

Would it be feasible to compare inline style CSS against editor CSS with Chrome as a temporary fix for the browser until Webkit issue is resolved?

comment:32 Changed 6 years ago by Piotrek Koszuliński

Most likely it was meant to be a feature, but it is very unwelcome feature. Webkit is just trying to do too much - it may look well (although I'm not sure about that), but the markup is corrupted. In the Blink/Webkit bug report I described other behaviours which seem to be related - all them pay too much attention to visual aspect of editing, but not to markup and API, so the result is ridiculous.

And yes, removing all styles from contents.css will help for some of these issues in framed editor. You may check the file attached to bug report - I also needed to apply some styling to trigger these "features". However, this is not going to help in inline editing, where it's normal that many styles are applied to the content and it does not prevent from element transformation.

Would it be feasible to compare inline style CSS against editor CSS with Chrome as a temporary fix for the browser until Webkit issue is resolved?

I'm not sure if I understand, but I think that you mean something similar to what Webkit is trying to do (but in the reverse way). And this definitely is not feasible (Webkit is good example of that :D).

If we're going to fix this, we'll try handling backspace completely manually. It is the only reasonable way, although it is also very complicated. Thus, first I'd like to have some feedback from Webkit/Blink's devs.

Last edited 6 years ago by Piotrek Koszuliński (previous) (diff)

comment:33 Changed 6 years ago by Piotrek Koszuliński

I created a bug report also on Webkit bug tracker: https://bugs.webkit.org/show_bug.cgi?id=114791

comment:34 Changed 6 years ago by Olek Nowodziński

Another possibly related ticket #10359.

comment:35 Changed 6 years ago by Piotrek Koszuliński

Description: modified (diff)

comment:36 Changed 6 years ago by jcisio

I think a quick fix for many user is to remove the SPAN element. I'd prefer to use semantic elements than SPAN, or even not SPAN at all in my configuration. Is there an easy way to remove SPAN elements on submit?

WebKit team won't revert this "feature" any time soon. I won't hold my breath (and I'd rather you didn't).

comment:37 Changed 6 years ago by Piotrek Koszuliński

You can reuse Advanced Content Filter which now filters only input data when getting data. If you configure it to not allow spans it will strip all of them.

The easiest way to do this is by changing true to false in this line: https://github.com/ckeditor/ckeditor-dev/blob/master/core/filter.js#L158. You should be able to find this fragment in built version or the best choice would be to grab dev version, change this line and build your own CKEditor package (it is very simple, using the instructions you can find here https://github.com/ckeditor/ckeditor-dev#readme).

If you don't want to rebuild editor, you can also add next toDataFormat listener (with correct priority) in which you'll call editor.filter.applyTo( evt.data.dataValue, false, true );. But that will be a little bit worse solution because transformations will be applied twice (by the original listener and new one).

To make this simpler I think that I'll add toDataFormat event's property similar to what toHtml already has (data.dontFilter).

comment:38 Changed 6 years ago by jcisio

I don't think that ACF accepts black listing now? I'm currently not using ACF (allowedContent = TRUE). I don't want to go with a custom build, or hack the core code neither. I'll try to look at the filter. Thanks.

comment:39 Changed 6 years ago by Piotrek Koszuliński

Nope - black listing is not yet implemented (#10276). And I even wasn't planning to make it working with disabled ACF (allowedContent==true). Although... it could be useful. Unfortunately this would mean rewriting bigger part of filter.js than in my previous plan.

Last edited 6 years ago by Piotrek Koszuliński (previous) (diff)

comment:40 Changed 6 years ago by sirtet

I am running into this with CKEditor 4.1 (revision 80c139aa). in chrome Version 26.0.1410.64 m

There are at least 2 workarounds suggested in here, can maybe someone describe these in a more end-user friendly way?

Maybe add it to the summary?

PS: I think this is probably a bigger problem than this tickes suggests, as a big part of users might never switch to source view, and therefore never see the cluttering... WebKit is... how big in % ?

PPS: My workaround is, to mark all content, and use the "remove formatting" button after i have done some editing...

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

comment:41 Changed 6 years ago by Jakub Ś

#10474 was marked as duplicate.

comment:42 Changed 6 years ago by santaclaus21

Problem still exist in Chrome 27.0.1453.110 m, CKE 4.1.2...

comment:43 Changed 6 years ago by Piotrek Koszuliński

Another related issue - #10515. This time caused by D&D.

comment:44 Changed 6 years ago by Piotrek Koszuliński

Description: modified (diff)
Note: See TracTickets for help on using tickets.
© 2003 – 2019 CKSource – Frederico Knabben. All rights reserved. | Terms of use | Privacy policy