Opened 11 years ago

Last modified 7 years ago

#9998 confirmed Bug

[Umbrella][Blink/Webkit] Issues related to backspace and delete keys handling

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 Jakub Ś)

This is an umbrella ticket for all issues related to backspace and delete keys handling caused by the following Webkit's and Blink's bugs:

Related tickets: #8438, #8439, #8440, #10359, #10515, #11483, #11592, #11415 and many others...


Cases

<span> created while joining two adjacent elements

Related issues: #9998

Target ticket: #11861

Example 1

  1. Set data
    <p>foo</p>
    <p>^bar</p>
    
  2. Backspace.
  3. <p>foo<span style="line-height:1.6">bar</span></p>

Example 2

  1. Set data
    <h1>foo</h1>
    <p>^bar</p>
    
  2. Backspace.
  3. <h1>foo<span style="font-size:13px; line-height:1.6">bar</span></h1>

<span> created while joining two adjacent elements (non-collapsed selection)

Related issues: #9998

Target ticket: #11980

Example 1

  1. Set data
    <div>
      <p>fo[o</p>
    </div>
    
    <div>
      <p>b]ar</p>
    </div>
    
  2. BACKSPACE
  3. Result:
    <div>
      <p>fo<span style="line-height:1.6">^ar</span></p>
    </div>
    
  4. Expected
    <div>
      <p>fo^ar</p>
    </div>
    

Attempt to preserve the visual style of the contents -> i.e. <strong> becomes <b>

Backspace (unable to remove formatting)

Related issues: #8438, #11592, #11483

  1. <p>x<strong>y^</strong></p>
  2. Backspace.
  3. Type “z”.
  4. <p>x<b>z^</b></p>

Backspace (underlined link becomes <u>)

Related issues: #11592

  1. <p><a href="http://foo">[foo]</a>bar</p>
  2. Backspace.
  3. Type "foo".
  4. <p><u>foo^</u>bar</p>
  5. Frown
  6. Grin

Note: This case uncovers the algorithm used in Webkit. The engine attempts to preserve the style no matter how ridiculous it would be – it uses <u> because it is the closest style, which corresponds visually with underlined link.

Del (unable to remove formatting)

Related issues: #8439, #8440, #12100

  1. <p>foo</p>
  2. CTRL+A.
  3. Bold.
  4. DEL.
  5. Type “bar”.
  6. <p><b>bar^</b></p>

Another example available in Blink browsers only:

  1. Switch to source mode and clear editor contents
  2. Paste this code <p><strong>test</strong></p>
  3. Press Ctrl+A
  4. Hit Backspace.

Result: Elements' path in Blink shows 'p' and when user starts typing text will be bold again. If user presses Backspace two times then whole formatting will be removed but there is no way for user to know that.

<span> created while splitting elements (DnD), extra &nbsp;

Related issues: #10515

  1. Set the following HTML
    <p>
        <span style="font-size:28px">
            foo 
            <strong>[bar]</strong> 
            <em>bam</em> 
            bang
        </span>
    </p>
    
  2. Drag [bar] into ba|m
  3. editor.getData().
  4. See the result.
    <p>
        <span style="font-size:28px">
            foo &nbsp;
            <em>ba</em>
        </span>
        <strong style="font-size:28px; line-height:44.79999923706055px">bar</strong>
        <em style="font-size:28px; line-height:1.6">m</em>
        <span style="font-size:28px; line-height:1.6"> bang</span>
    </p>
    
  5. Then WYSIWYG->Source->WYSIWYG.
  6. ACF brings the ultimate destruction.
    <p>
        <span style="font-size:28px">foo &nbsp;<em>ba</em></span>
        <strong>bar</strong>
        <em>m</em>
        <span style="font-size:28px"> bang</span>
    </p>
    

Change History (94)

comment:1 Changed 11 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 11 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 11 years ago by Jakub Ś (previous) (diff)

comment:3 Changed 11 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 11 years ago by lollypopstar

Cc: laura@… added

comment:5 Changed 11 years ago by Jakub Ś

#10064 was marked as duplicate.

comment:6 Changed 11 years ago by mandius

Cc: ben@… added

Adding as CC

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

Description: modified (diff)

comment:8 Changed 11 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 11 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 11 years ago by mandius

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

comment:11 Changed 11 years ago by lmeurs

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

comment:12 Changed 11 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 11 years ago by Jakub Ś

#10133 was marked as duplicate.

comment:14 in reply to:  11 Changed 11 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 11 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 11 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 11 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 11 years ago by Matti Järvinen

Cc: matti.jarvinen@… added

following cc

comment:19 Changed 11 years ago by ivanjh

Cc: ivanjh@… added

Also affects 26.0.1410.43 (Win & Mac)

comment:20 Changed 11 years ago by Berry

Experiencing the same issue, following cc

comment:21 Changed 11 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 11 years ago by Chris

Also experiencing on Ubuntu Chromium 25.0.1364.160

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

comment:23 Changed 11 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 11 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 11 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 11 years ago by Piotrek Koszuliński

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

comment:27 Changed 11 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 11 years ago by crisward (previous) (diff)

comment:28 Changed 11 years ago by ryanissamson

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

comment:29 Changed 11 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 11 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 11 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 11 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 11 years ago by Piotrek Koszuliński (previous) (diff)

comment:33 Changed 11 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 11 years ago by Olek Nowodziński

Another possibly related ticket #10359.

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

Description: modified (diff)

comment:36 Changed 11 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 11 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 11 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 11 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 11 years ago by Piotrek Koszuliński (previous) (diff)

comment:40 Changed 11 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 11 years ago by sirtet (previous) (diff)

comment:41 Changed 11 years ago by Jakub Ś

#10474 was marked as duplicate.

comment:42 Changed 11 years ago by santaclaus21

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

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

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

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

Description: modified (diff)

comment:45 Changed 11 years ago by pr0nbaer

I created a plugin to fix this issue in webkit browsers.. http://pastebin.com/XUC7rCdn

  • It removes spans created by webkit browsers
  • It preserves existing spans created by the user
  • Logs information on the console when removing, merging etc.
Last edited 11 years ago by pr0nbaer (previous) (diff)

comment:46 in reply to:  45 ; Changed 11 years ago by Roman

Replying to pr0nbaer:

Hi pr0nbaer,

Thats great, i just tested it, works perfect! If you do not mind created the github repo https://github.com/RomanMinkin/webkit-span-fix I made some linting and improvements.

comment:47 in reply to:  46 ; Changed 11 years ago by pr0nbaer

Replying to minkinroman@…:

Feel free to update the german comments ;) Took me 2 days to create this fix - had to much left time in my job :D

If someone doesn't know how my fix works, heres a simple explanation:

Basic Information:

  • Webkit will insert/update span Elements in the short time when the keyDown and the keyUp event is triggered
  • Webkit updates ALL Elements within the last block element that is being merged within another (Block Elements are all element with display:block as computed style

Fix:

  1. When the keyDown event is fired, all Element- or text-nodes-siblings directly after the selection (or cursor) within (direct children, not children-chilren..) the last merged block element are saved in an array -> They are not affected at this time of the webkit-span-update
  2. Directly after the keyDown event, the keyUp event is bound to the editor once. When the keyUp event is fired (and webkit has already updated the spans) the same thing as in step 1 will be done with the new selection, and all siblings are saved to another array
  3. Before the fix will start to replace or remove Elements from the array of step 1 with the array of step 2, it will find out if 2 block elements have been merged when the whole keypress is done
  4. If so, a difference is being created from the step1-array and step2-array. If a element in the step2-array is a span, but the element on the same index in the step1-array is not a span, the span will be removed and replaced with its contents; if a element in the step2-array is a span with styles in the style-attribute, and the element on the same index in the step1-array is also a span with style-attribute, but the style differs, the style-Element is being copied from the step1-array-element to the step2-array-element.

comment:48 in reply to:  47 Changed 11 years ago by Roman

Replying to pr0nbaer:

Replying to minkinroman@…:

Feel free to update the german comments ;) Took me 2 days to create this fix - had to much left time in my job :D

Heh, i will, later -) Thanks for description, added. If you have github account I can add you to the repo.

comment:49 Changed 11 years ago by santaclaus21

Dear CKEditor programmers... maybe it's time to include this fix to code? Bug is open from 6 months and problem still exists in version 4.2. Thanks.

comment:50 Changed 11 years ago by Piotrek Koszuliński

We would love to be able to include it. We haven't got any response from Blink's team (not only for this issue...), so it's time to hack it on our side.

Although, we can't include so complex patch without heavily testing it and improving (from my experience I know that there still will be a lot of work). Unfortunately, before 4.3 we won't have enough time because of widgets (#9764), so 4.4 is the closest possible release.

comment:51 Changed 11 years ago by pr0nbaer

That's right. My plugin is just a hotfix, fixing only a small amount of use-cases of this problem. There are certain circumstances webkit is trying to make inline-styles and not even on spans!

  • Webkit trys to add inline-styles to all inline-elements (strong, span, em, etc.) when block elements are merged
  • Drag'n'Drop of text snippets to other block elements triggers also this behavior

...

I'll give my best trying to fix all use-cases and to test it as well, but it will take some time until the whole plugin will fix the whole webkit problem without creating new issues.

pr0nbaer.

comment:52 in reply to:  51 ; Changed 11 years ago by Andre

Replying to pr0nbaer:

Hi, I was also facing this problem to the past few days and I've used your plugin as a solution. It worked fine to remove the span tags and I was making some changes to fix the problem with adding inline-styles for inline-elements. Turns out I ended up finding a much simpler solution reading this post http://ckeditor.com/forums/CKEditor/ckeditor-4.01-inserting-span-elements-everywhere-with-a-line-height-of-1.6em

The line-height style will be added according to the line-height setted for the class ".cke-editable". Changing the line-height of this class to 1.0em for example, would generate a span tag with "style='line-height: 1.0em'" from now on.

The solution was to add this line to a custom css file or simply changing the original css file to apply this style:

.cke_editable{ line-height: normal } 

Actually the problem only occurs if you let a line-height with a "em" value. The problem does not occur even if you add value in "px", don't ask me why...

Maybe CKEditor is trying to adjust the line-height of its contents according to the parents elements and makes a mess trying to do it, and by setting a fixed value CKEditor avoids this behavior. Maybe..

I hope this helps.

Andre Rodrigues.

Last edited 11 years ago by Andre (previous) (diff)

comment:53 in reply to:  52 Changed 11 years ago by pr0nbaer

Replying to andre.rodrigues:

Very nice! This really fixes the behavior. But there are still problems left: When merging a paragraph with a headline (h1 etc.) CKEditor tries to adjust the color and font-size and inserts a span with style..

comment:54 Changed 11 years ago by Piotrek Koszuliński

CKEditor avoids this behavior

CKEditor tries to adjust

CKEditor does not do anything here. It was mentioned many times in this thread - this is a Blink's (Chrome, Chromium) bug.

Also, it was mentioned that not using any styles for your content can partially fix this issue.

comment:55 Changed 10 years ago by santaclaus21

@Reinmar: "so 4.4 is the closest possible release" - so, we are awaiting.

comment:56 Changed 10 years ago by Marek Lewandowski

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

adding blink tag to issue summary

comment:57 Changed 10 years ago by Joel

Cc: joel.peltonen@… added

CC

comment:58 Changed 10 years ago by Jakub Ś

#11367 was marked as duplicate.

comment:59 Changed 10 years ago by Jakub Ś

#11553 was marked as duplicate.

comment:60 Changed 10 years ago by Mike Gifford

We're seeing this problem too.

I don't see this ticket appearing in the 4.4 roadmap http://dev.ckeditor.com/roadmap

@Reinmar If this is a Chrome bug, is there an attempt to provide a work around.

Is our only solution in the interim to tell folks that they will have a better experience using FireFox? If so should that be put in the release notes?

comment:61 Changed 10 years ago by Piotrek Koszuliński

We think about this issue constantly, but it requires a lot of effort to be fully and correctly fixed. I presume that we'll work on it in CKEditor 4.5, so for now using different browser or one of mentioned hack (like in comment:52 or https://twitter.com/NXRK/status/432507320224858112) is the only solution.

comment:62 Changed 10 years ago by Piotrek Koszuliński

Description: modified (diff)

comment:63 Changed 10 years ago by Marek Lewandowski

Description: modified (diff)

#11592 was marked as duplicate.

comment:64 Changed 10 years ago by Piotr Jasiun

The issue still exists in 4.3.3 and Chrome 31.

It could be reproduced in "Massive inline editing" sample if you try to merge two paragraph in the top right editor ("Lorem ipsum dolor sit amet [...] malesuada ultricies." and "Curabitur et ligula. [...]") using delete or backspace.

comment:65 Changed 10 years ago by santaclaus21

"Opened 13 months ago". Maybe in 4.4, maybe in 4.5 or maybe...

comment:66 Changed 10 years ago by Piotr Jasiun

I fact this is a Chrome (Blink) issue. What we can do with it is to write our custom backspace/delete handler, but this it pretty big change in the editor.

comment:67 Changed 10 years ago by brett

Please fix. THis issue happens to me when I merge paragraphs together as well as if I drag and drop or copy and paste.

LINE-HEIGHT everywhere. The above plugin did fix the merging paragraphs issue but not the issue with the copy and pasting.

comment:68 Changed 10 years ago by brett

Please fix. THis issue happens to me when I merge paragraphs together as well as if I drag and drop or copy and paste.

LINE-HEIGHT everywhere. The above plugin did fix the merging paragraphs issue but not the issue with the copy and pasting.

comment:69 Changed 10 years ago by Ken

This is still a big problem for us. We love CKEditor but may need to look into other options if this doesn't get resolved. Definitely more important than any new features or any other bugs we know of.

comment:70 Changed 10 years ago by brett

Here is how we fixed it: For the SPANs that get added when merging paragraphs we used ​https://github.com/RomanMinkin/webkit-span-fix

For the copy and paste SPANs we updated the paste plugin to strip all <spans> on page

works great now.

comment:71 Changed 10 years ago by Ken

Thanks brettr, we'll check it out. Much appreciated.

comment:72 Changed 10 years ago by Piotrek Koszuliński

We understand the importance of this issue. We have to admit now that waiting for Blink/Webkit fix was pointless and exposed users for encountering this issue for too long. But to be honest we didn't expect that browser vendors will ignore such issue.

Regarding our plans - we'll start working on this ticket right after releasing CKEditor 4.4. We also agreed that if it won't require public API changes, we'll include it before 4.5, so in one of minor releases after 4.4 and therefore we haven't yet set the milestone for it.

comment:73 Changed 10 years ago by rlull

I've got a unique spin on this situation. We're using Kentico CMS v7 which is using version 3.6.3 of CKeditor. I tried the plugin fix from github but it doesn't work. Any chance there's a fix for this older version? I'm checking with Kentico to see if I can update to the latest version but suspect there may be compatibility issues.

comment:73 Changed 10 years ago by rlull

I've got a unique spin on this situation. We're using Kentico CMS v7 which is using version 3.6.3 of CKeditor. I tried the plugin fix from github but it doesn't work. Any chance there's a fix for this older version? I'm checking with Kentico to see if I can update to the latest version but suspect there may be compatibility issues.

comment:74 Changed 10 years ago by Jakub Ś

Fix will only be provided for CKE 4.x

Last edited 10 years ago by Jakub Ś (previous) (diff)

comment:75 Changed 10 years ago by santaclaus21

Additional fix from github is NOT always working. eg in case of html5 tags. So we should be patient for resolving problem by CKE team.

comment:76 Changed 10 years ago by santaclaus21

What about this ticket? We had two compilations in this week, no changes. What about millestone:

http://dev.ckeditor.com/query?group=status&milestone=CKEditor+4.4.1 http://dev.ckeditor.com/query?group=status&milestone=CKEditor+4.5.0

Somebody from CKE promised me that they are start working on #9998 in few days (?). Who is setting a milestone? We understand that this is a bug in Chrome, but ~40% people are using Chrome. How many percent of CKE users are using widgets (?) So what is more important?

Last edited 10 years ago by santaclaus21 (previous) (diff)

comment:77 Changed 10 years ago by Piotrek Koszuliński

CKEditor 4.4.0 which was released yesterday was set many months ago and we couldn't fit anything more in it, because it was already delayed. CKEditor 4.3.5 was, as you can see, just a maintanance release and did not contain any serious changes.

As I explained in comment:72, we planned to start working on this issue right after releasing CKEditor 4.4.0, so we actually started to work on it yesterday. We don't set any milestones yet, because we don't know which parts of this huge issue we will be able to fix when. Our goal is to provide a fix for most important cases in CKEditor 4.4.1, so in 3 weeks. Then we'll work on refining more and more cases and perhaps propose an ultimate solution in CKEditor 4.5.

Therefore, this ticket will not be assigned to any milestone, because it's an "umbrella" ticket for all kinds of issues regarding backspace and delete handling. We'll just rewrite it so it contains a clear list of TCs. Then we'll create subtickets which will be assigned to milestones. First will be assigned to CKEditor 4.4.1.

comment:78 Changed 10 years ago by Olek Nowodziński

Description: modified (diff)

comment:79 Changed 10 years ago by Olek Nowodziński

Description: modified (diff)

comment:80 Changed 10 years ago by Piotrek Koszuliński

Description: modified (diff)
Keywords: Blink Webkit added; Chrome removed
Summary: [Blink] In Chrome SPAN tags appear when merging paragraphs with delete/backspace.[Umbrella][Blink/Webkit] Issues related to backspace and delete keys handling
Version: 4.0

comment:81 Changed 10 years ago by Piotrek Koszuliński

First part of this huge bug is now fixed: http://dev.ckeditor.com/ticket/11861#comment:20 (this patch will be included in CKEditor 4.4.1). In CKEditor 4.4.2 we'll work on non-collapsed selections.

comment:82 Changed 10 years ago by santaclaus21

awaiting for 4.4.1. All tickets assigned to this version milestone are closed as can we see. So... :) Night build is looking good!

comment:83 Changed 10 years ago by Piotrek Koszuliński

Yes, we're in a testing phase. It's going well - no regressions so far, so release should be done next Tuesday, as scheduled. Most likely no more changes except translations, will be made on master.

comment:84 Changed 10 years ago by Olek Nowodziński

Description: modified (diff)

comment:85 Changed 10 years ago by Jakub Ś

#9146 is perhaps related to this issue and could be included in fix.

comment:86 Changed 10 years ago by Jakub Ś

Description: modified (diff)

comment:87 Changed 10 years ago by Darrin Wortlehock

same issue occurs when dragging a paragraph to a different location in the editor. paragraph is inserted with spans specifying line height.

comment:88 Changed 10 years ago by Piotrek Koszuliński

Yes, this is because we don't handle DnD in a totally custom way yet (we let Chrome do as it wishes). We work on this for the 4.5.0 milestone and the works are in an advanced stage.

comment:89 Changed 9 years ago by Vikki

There is also in issue using the keyboard shortcut Control+h on the Mac with Chrome 38.x to backspace a paragraph into the paragraph above.

<p>This is the first paragraph</p>

<p>This is the second paragraph</p>

Do a Control+h with your cursor at the beginning of the second paragraph and you end up with this:

<p>This is the first paragraph.<span style="font-size: inherit; line-height: 1.6;">This is the second paragraph.</span></p>

Each subsequent paragraph after that above will then have the span style in them.

comment:90 Changed 9 years ago by Jason

I'm using 4.4.2 with Chrome 44.0.2403 on Windows and can confirm that this issue is still occurring when using the backspace or delete. The same steps in Firefox do not result in the extra span tag & inline styles being added.

comment:91 in reply to:  90 Changed 9 years ago by Olek Nowodziński

Replying to jasolution:

I'm using 4.4.2 with Chrome 44.0.2403 on Windows and can confirm that this issue is still occurring when using the backspace or delete. The same steps in Firefox do not result in the extra span tag & inline styles being added.

Did you try updating to the latest version?

comment:92 Changed 8 years ago by Jakub Ś

Description: modified (diff)

comment:93 Changed 7 years ago by Wiktor Walc

Priority: HighNormal
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