New issue
Advanced search Search tips
Starred by 60 users
Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: 2017-04-25
OS: ----
Pri: 3
Type: Bug


Show other hotlists

Hotlists containing this issue:
test
Top-Starred-Bugs


Sign in to add a comment
Contenteditable issues related to backspace handling
Reported by pkoszuli...@gmail.com, Apr 5 2013 Back to list
Chrome Version       : 25.0.1364.172
Other browsers tested:
       Safari 6: TC1&TC2 OK, TC3&TC4 BAD
   Firefox 19.x: TC1 OK, TC2 :|, TC3 OK, TC4 mostly OK
           IE 9: TC1&TC2&TC3 OK, TC4 mostly OK

Hi,
I'm a CKEditor core developer. Our users reported few issues for how backspace works. They complain mainly about undesirable <span> elements, but also about other aspects.

I gathered four test cases in backspace.html (which I'm attaching). It contains scenarios, expected and actual outputs.

I'm aware that these are separate issues, but I report them together because I noticed that they are related to the same concept. When handling backspace (and other actions too) Webkit/Blink, instead of working on DOM, works on internal representation of editable element contents which seems to be something like "unstructured styled text".

E.g. in TC2 Webkit does not merge <h1> and <p> elements, but text having big font size and text having small font size and the result is <span> element which keeps the style of removed paragraph.

TC3 is another interesting example. Webkit removes <strong> element, but internally keeps information about the style and when user starts typing again it tries to recreate this style... which gives us <b> element or even worse <font> elements in other cases. TC4.2 is another interesting case - even if entire paragraph is deleted, Webkit recreates the style.


Conclusion

From our (CKEditor's) and most of our users' POV current behaviour is undesirable. Webkit pays attention to visual result, but HTML it produces is terrible. It's impossible to create decent WYSIWYG editor for people that care about semantically correct HTML without writing custom backspace (and other keys) handling from scratch.

Two most important proposals:

* Webkit should not keep internally information about styles - everything should be "on paper". In DOM there is a <strong> element, then we are editing <strong> element, not bold text. The <strong> element has been removed from DOM, then it's gone forever. When I press delete between header and paragraph, paragraph should be merged to header, not small text to big text.
* All actions should be done from DOM POV. As an operations on DOM, not on visual representation of editable element contents.

 
backspace.html
4.2 KB View Download
PS. Should I crosspost this report on Webkit bug tracker?
Comment 3 by hai...@gmail.com, Apr 15 2013
Tested with Chrome 27 beta. Get nasty results in all test cases. BTW we should report in webkit trac, too, as it also happens in Safari.

I skimmed over the webkit commits between Jan 2013 and Nov 2012, the only doubtful commit is https://trac.webkit.org/changeset/135421 (I never read WebKit code, so it may be a positive false).
This is 4 months now and no response at all. These issues were reported to us and on StackOverflow dozens of times in the meantime. It would be cool if we had at least a confirmation that Blink's team is not going to work on them.
Comment 6 by peta...@gmail.com, Sep 25 2013
It would be great if this could be fixed. It effects many users. 
the same here - Chrome 32.0.1671.3 (Official Build 228616) dev
Labels: cr-blink Cr-Blink-Editing
Comment 9 by aza...@gmail.com, Dec 12 2013
We've been dealing with the same issue in WordPress for a while now. It also happens on InsertUnorderedList, InsertOrderedList, and possibly other native contenteditable commands. Also on dragging selected text from one node to another.

Despite that TinyMCE (the default editor in WordPress) includes several DOM level fixes, these spans still get inserted sometimes. The more styling there is in the contenteditable element, the higher the chance these unwanted spans will appear. The only sure way to stop them is to remove all text styling inside the editor. Of course this is the exact opposite of what WYSIWYG is all about.
Comment 10 Deleted
Comment 11 Deleted
Comment 12 by ide...@gmail.com, Jan 27 2014
This is a bug with contentEditable fields in chrome that is affecting thousands of developers, it is widely referenced online:

http://www.neotericdesign.com/blog/2013/3/working-around-chrome-s-contenteditable-span-bug

https://code.google.com/p/chromium/issues/detail?can=2&start=0&num=100&q=&colspec=ID%20Pri%20M%20Iteration%20ReleaseBlock%20Cr%20Status%20Owner%20Summary%20OS%20Modified&groupby=&sort=&id=226941

http://stackoverflow.com/questions/15015019/prevent-chrome-from-wrapping-contents-of-joined-p-with-a-span

We really need to have this fixed,
please google chrome team, could you please do something about it, it's really affecting our work and apps, thanks very much

Comment 13 by le...@chromium.org, Jan 27 2014
Cc: yosin@chromium.org yoichio@chromium.org
Comment 14 by le...@chromium.org, Jan 27 2014
Status: Available
Comment 15 by aza...@gmail.com, Jan 27 2014
Related: https://code.google.com/p/chromium/issues/detail?id=335955 and https://bugs.webkit.org/show_bug.cgi?id=127242

Still can't find the reasoning behind inserting all these spans... 
Comment 16 by ide...@gmail.com, Jan 27 2014
i totally agree, 
so far the partial patch i found is doing this

this.$editor.find( "span" ).contents().unwrap();
this.$editor.find( "p" ).prepend('<br />').contents().unwrap();
this.$editor.find( "div" ).prepend('<br />').contents().unwrap();

after editing ends, 
of course not ideal at all,
a patch while we wait for google to fix this

Comment 17 by Deleted ...@, Jan 27 2014
Yea, I would love to see a fix for this. It is very annoying for content editors. They end up either having to edit the source (if they even know how), or switch to Firefox to do some tasks. 
I also really want to see this fixed. It is extremely hard to work around due to the number of different cases that cause it.

https://github.com/PANmedia/raptor-editor/issues/122
Comment 19 by Deleted ...@, Feb 7 2014
I really don't see why we can't have the option to completely disable any and all creation of <span>, inline style, and any other markup. Text only. Please. We can handle any needed markup ourselves, and it's much more simple than removing yours.
The best thing is that I can't imagine why would any one want contenteditable to work like that. It's totally against reasonable behaviour.
Comment 21 by ide...@gmail.com, Feb 7 2014
i totally agree, it doesn't make sense
We're going to have to recommend to our clients that they not use Chrome until this is fixed.  It's certainly not our preference, but this works fine in other modern browsers. 
Comment 23 by Deleted ...@, Feb 18 2014
We are also recommending that people use Firefox instead of Chrome because of this issue. It's a shame really, it's my preferred browser but this issue is a real killer for us. 
We're also switching back to FireFox now.
I've just seen the most ridiculous TC for this issue:

1. <p><a href="http://foo">foo</a>bar</p>
2. Select "foo".
3. Press delete.
4. Start typing... your text is underlined, but it's not a link any more. It's <u>.

This can even be reproduced in Gmail.
Comment 26 by Deleted ...@, Mar 13 2014
I suggest use Microsft Internet Explorer :b
Labels: Editing-FixIt
Cc: jparent@chromium.org
PLEASE, fix it. I'm using Chrome from 3 years and now I'm going to use Firefox back :( PLEASE do something with that. It happens also on HTML5 tags.

Cc: kenjibaheux@chromium.org
Issues around contentEditable have been brought up at the Extensible Web Summit in April 2014. The concept of a contentEditable="minimal" (TBD) was introduced and got some reasonable initial support. 

In short, contentEditable="minimal" is about providing you the primitives that would let you build the editing solution that fits your needs instead of the current situation where you have to fight against a set of already defined (yet incompatible :( ) behaviors.

The Blink-editing team believes in this approach.

We are now looking for broader feedback: we want to make sure that this solution will indeed solve your needs. Please take the time to read the announcement and links sent to public-webapps and help us get this right by providing your insights on the topic.


Extensible Web Summit - Editing session:
 http://lanyrd.com/2014/extensible-web-summit/scyqtr/

Announcement of contentEditable="minimal" thread on public-webapps: 
 http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0296.html
Comment 31 Deleted
Also, relevant: the concept of CommandEvents which would untie user intents from the underlying mean used. Example: in addition(*) of getting raw event for Ctrl-a, you would get the actual intent (i.e. select all).

This is becoming and increasingly important aspect given the growing range of editing options popularized by mobile platforms (e.g. speech input, gestures...).


Feedback on this particular topic is also welcomed: http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0298.html


(*: updated; was 'instead'. Note: this still is an assumption at this point).
Thanks for the info. We will try to give a feedback soon. I agree that contenteditable=minimal makes sense, as it will relieve browser vendors of the need to maintain such complex and not standardised. However, this mode must implement all the editing features which are hard or even impossible to achieve in JavaScript, so they have to be chosen wisely.
Comment 34 by yosin@chromium.org, Aug 28 2014
Labels: Cr-Blink-Editing-Command
Comment 35 Deleted
Labels: -cr-blink
Cc: -kenjibaheux@chromium.org
Project Member Comment 38 by bugdroid1@chromium.org, Jun 13 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/8e411d16171d27612776a2f05356b0ed9f06b848

commit 8e411d16171d27612776a2f05356b0ed9f06b848
Author: joone.hur <joone.hur@intel.com>
Date: Mon Jun 13 06:55:43 2016

Don't need to preserve CSS line-height property during editing operation

When we merge two paragraphs by typing backspace key at the head
of the second paragraph, the styles of the second paragraph can be
preserved by using <span> tag. However, we don't need to preserve
line-height style because the computed value can be different from
the value defined in HTML.

BUG=226941
TEST=editing/deleting/backspace-merge-two-paragraphs.html

Review-Url: https://codereview.chromium.org/2064473002
Cr-Commit-Position: refs/heads/master@{#399410}

[add] https://crrev.com/8e411d16171d27612776a2f05356b0ed9f06b848/third_party/WebKit/LayoutTests/editing/deleting/backspace-merge-two-paragraphs.html
[modify] https://crrev.com/8e411d16171d27612776a2f05356b0ed9f06b848/third_party/WebKit/LayoutTests/editing/pasteboard/data-transfer-items-expected.txt
[modify] https://crrev.com/8e411d16171d27612776a2f05356b0ed9f06b848/third_party/WebKit/LayoutTests/editing/pasteboard/dragstart-contains-default-content-expected.txt
[modify] https://crrev.com/8e411d16171d27612776a2f05356b0ed9f06b848/third_party/WebKit/LayoutTests/editing/pasteboard/onpaste-text-html-expected.txt
[modify] https://crrev.com/8e411d16171d27612776a2f05356b0ed9f06b848/third_party/WebKit/LayoutTests/fast/events/ondrop-text-html-expected.txt
[modify] https://crrev.com/8e411d16171d27612776a2f05356b0ed9f06b848/third_party/WebKit/Source/core/editing/EditingStyle.cpp
[modify] https://crrev.com/8e411d16171d27612776a2f05356b0ed9f06b848/third_party/WebKit/Source/web/tests/WebViewTest.cpp

Project Member Comment 39 by bugdroid1@chromium.org, Jun 15 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/8e411d16171d27612776a2f05356b0ed9f06b848

commit 8e411d16171d27612776a2f05356b0ed9f06b848
Author: joone.hur <joone.hur@intel.com>
Date: Mon Jun 13 06:55:43 2016

Don't need to preserve CSS line-height property during editing operation

When we merge two paragraphs by typing backspace key at the head
of the second paragraph, the styles of the second paragraph can be
preserved by using <span> tag. However, we don't need to preserve
line-height style because the computed value can be different from
the value defined in HTML.

BUG=226941
TEST=editing/deleting/backspace-merge-two-paragraphs.html

Review-Url: https://codereview.chromium.org/2064473002
Cr-Commit-Position: refs/heads/master@{#399410}

[add] https://crrev.com/8e411d16171d27612776a2f05356b0ed9f06b848/third_party/WebKit/LayoutTests/editing/deleting/backspace-merge-two-paragraphs.html
[modify] https://crrev.com/8e411d16171d27612776a2f05356b0ed9f06b848/third_party/WebKit/LayoutTests/editing/pasteboard/data-transfer-items-expected.txt
[modify] https://crrev.com/8e411d16171d27612776a2f05356b0ed9f06b848/third_party/WebKit/LayoutTests/editing/pasteboard/dragstart-contains-default-content-expected.txt
[modify] https://crrev.com/8e411d16171d27612776a2f05356b0ed9f06b848/third_party/WebKit/LayoutTests/editing/pasteboard/onpaste-text-html-expected.txt
[modify] https://crrev.com/8e411d16171d27612776a2f05356b0ed9f06b848/third_party/WebKit/LayoutTests/fast/events/ondrop-text-html-expected.txt
[modify] https://crrev.com/8e411d16171d27612776a2f05356b0ed9f06b848/third_party/WebKit/Source/core/editing/EditingStyle.cpp
[modify] https://crrev.com/8e411d16171d27612776a2f05356b0ed9f06b848/third_party/WebKit/Source/web/tests/WebViewTest.cpp

Comment 40 by yosin@chromium.org, Jun 28 2016
Cc: -yoichio@chromium.org -jparent@chromium.org -yosin@chromium.org
Owner: yosin@chromium.org
Status: Started
joone.hur@ is working: http://crrev.com/2102913002
yosin@ is a virtual owner.
Project Member Comment 41 by bugdroid1@chromium.org, Jun 29 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/5220699381aae450f22d1ea3805141deb139f8f3

commit 5220699381aae450f22d1ea3805141deb139f8f3
Author: joone.hur <joone.hur@intel.com>
Date: Wed Jun 29 02:15:00 2016

Remove style spans to follow the styles of the block element

This CL removes style spans to follow the styles of the block
element(li, pre, td, and h1~6) when the text of the pasted
or merged element becomes a part of the block element.

BUG=226941
TEST=third_party/WebKit/LayoutTests/editing/deleting/backspace-merge-into-block-element.html

Review-Url: https://codereview.chromium.org/2102913002
Cr-Commit-Position: refs/heads/master@{#402659}

[add] https://crrev.com/5220699381aae450f22d1ea3805141deb139f8f3/third_party/WebKit/LayoutTests/editing/deleting/backspace-merge-into-block.html
[delete] https://crrev.com/4ce66b514986428274bea5eb1aed306d164f1662/third_party/WebKit/LayoutTests/editing/deleting/backspace-merge-into-list-item.html
[modify] https://crrev.com/5220699381aae450f22d1ea3805141deb139f8f3/third_party/WebKit/LayoutTests/editing/deleting/merge-paragraph-from-p-with-style-3-expected.txt
[modify] https://crrev.com/5220699381aae450f22d1ea3805141deb139f8f3/third_party/WebKit/Source/core/editing/commands/ReplaceSelectionCommand.cpp

Project Member Comment 42 by bugdroid1@chromium.org, Jun 29 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/45859e627709ac2a56e939a00f725a0fca27f75f

commit 45859e627709ac2a56e939a00f725a0fca27f75f
Author: shans <shans@chromium.org>
Date: Wed Jun 29 03:06:25 2016

Revert of Remove style spans to follow the styles of the block element (patchset #2 id:20001 of https://codereview.chromium.org/2102913002/ )

Reason for revert:
Assignment within conditional on line 836 of ReplaceSelectionCommand.cpp is breaking Win8 build:

https://build.chromium.org/p/chromium.win/builders/Win8%20GYP%20%28dbg%29/builds/133

Original issue's description:
> Remove style spans to follow the styles of the block element
>
> This CL removes style spans to follow the styles of the block
> element(li, pre, td, and h1~6) when the text of the pasted
> or merged element becomes a part of the block element.
>
> BUG=226941
> TEST=third_party/WebKit/LayoutTests/editing/deleting/backspace-merge-into-block-element.html
>
> Committed: https://crrev.com/5220699381aae450f22d1ea3805141deb139f8f3
> Cr-Commit-Position: refs/heads/master@{#402659}

TBR=yosin@chromium.org,joone.hur@intel.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=226941

Review-Url: https://codereview.chromium.org/2109973002
Cr-Commit-Position: refs/heads/master@{#402696}

[delete] https://crrev.com/625e2c8105ebb18772ac3cd939d9bbeef48cde56/third_party/WebKit/LayoutTests/editing/deleting/backspace-merge-into-block.html
[add] https://crrev.com/45859e627709ac2a56e939a00f725a0fca27f75f/third_party/WebKit/LayoutTests/editing/deleting/backspace-merge-into-list-item.html
[modify] https://crrev.com/45859e627709ac2a56e939a00f725a0fca27f75f/third_party/WebKit/LayoutTests/editing/deleting/merge-paragraph-from-p-with-style-3-expected.txt
[modify] https://crrev.com/45859e627709ac2a56e939a00f725a0fca27f75f/third_party/WebKit/Source/core/editing/commands/ReplaceSelectionCommand.cpp

Project Member Comment 43 by bugdroid1@chromium.org, Jun 29 2016
Labels: merge-merged-2783
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/51a4fa51c42248a39489ddd18faa281e81b2bbc8

commit 51a4fa51c42248a39489ddd18faa281e81b2bbc8
Author: yosin <yosin@chromium.org>
Date: Wed Jun 29 06:00:59 2016

Revert of Remove style spans to follow the styles of the block element (patchset #2 id:20001 of https://codereview.chromium.org/2102913002/ )

Reason for revert:
Assignment within conditional on line 836 of ReplaceSelectionCommand.cpp is breaking Win8 build:

https://build.chromium.org/p/chromium.win/builders/Win8%20GYP%20%28dbg%29/builds/133

crbug.com/624263 tracks build failures

Original issue's description:
> Remove style spans to follow the styles of the block element
>
> This CL removes style spans to follow the styles of the block
> element(li, pre, td, and h1~6) when the text of the pasted
> or merged element becomes a part of the block element.
>
> BUG=226941
> TEST=third_party/WebKit/LayoutTests/editing/deleting/backspace-merge-into-block-element.html
>
> Committed: https://crrev.com/5220699381aae450f22d1ea3805141deb139f8f3
> Cr-Commit-Position: refs/heads/master@{#402659}

TBR=yosin@chromium.org,joone.hur@intel.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=226941

Review-Url: https://codereview.chromium.org/2109973002
Cr-Commit-Position: refs/heads/master@{#402696}
(cherry picked from commit 45859e627709ac2a56e939a00f725a0fca27f75f)

Review-Url: https://codereview.chromium.org/2111473002
Cr-Commit-Position: refs/branch-heads/2783@{#2}
Cr-Branched-From: 956d75c97da94022381b07c336a4c258b04fb8bc-refs/heads/master@{#402676}

[delete] https://crrev.com/29f0403bc683537bd4512fc211d296ab9d3f9f07/third_party/WebKit/LayoutTests/editing/deleting/backspace-merge-into-block.html
[add] https://crrev.com/51a4fa51c42248a39489ddd18faa281e81b2bbc8/third_party/WebKit/LayoutTests/editing/deleting/backspace-merge-into-list-item.html
[modify] https://crrev.com/51a4fa51c42248a39489ddd18faa281e81b2bbc8/third_party/WebKit/LayoutTests/editing/deleting/merge-paragraph-from-p-with-style-3-expected.txt
[modify] https://crrev.com/51a4fa51c42248a39489ddd18faa281e81b2bbc8/third_party/WebKit/Source/core/editing/commands/ReplaceSelectionCommand.cpp

Project Member Comment 44 by bugdroid1@chromium.org, Jul 1 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/7cd91bcaaf5ef14b3e76465b464902cd864eaea0

commit 7cd91bcaaf5ef14b3e76465b464902cd864eaea0
Author: joone.hur <joone.hur@intel.com>
Date: Fri Jul 01 08:59:24 2016

[Reland] Remove style spans to follow the styles of the block element

Note: The original CL was reverted because of breaking Win8 build:
https://codereview.chromium.org/2109973002/

This CL removes style spans to follow the styles of the block
element(li, pre, td, and h1~6) when the text of the pasted
or merged element becomes a part of the block element.

BUG=226941
TEST=third_party/WebKit/LayoutTests/editing/deleting/backspace-merge-into-block-element.html

Review-Url: https://codereview.chromium.org/2117663002
Cr-Commit-Position: refs/heads/master@{#403428}

[add] https://crrev.com/7cd91bcaaf5ef14b3e76465b464902cd864eaea0/third_party/WebKit/LayoutTests/editing/deleting/backspace-merge-into-block.html
[delete] https://crrev.com/deec23f32462827a76e3524d04fa6b13784a6ec8/third_party/WebKit/LayoutTests/editing/deleting/backspace-merge-into-list-item.html
[modify] https://crrev.com/7cd91bcaaf5ef14b3e76465b464902cd864eaea0/third_party/WebKit/LayoutTests/editing/deleting/merge-paragraph-from-p-with-style-3-expected.txt
[modify] https://crrev.com/7cd91bcaaf5ef14b3e76465b464902cd864eaea0/third_party/WebKit/Source/core/editing/commands/ReplaceSelectionCommand.cpp

Labels: -Editing-FixIt Editing-Fixit
Comment 46 by dk...@chromium.org, Mar 22 2017
Has this bug been fixed?
I tried to fix all the cases, but there might be more cases.
Comment 48 by yosin@chromium.org, Mar 23 2017
Owner: ----
Status: Available
Labels: Hotlist-Interop
Status: Untriaged
The predictability program is reviewing the top 50 starred Blink bugs this quarter, and this is #41 on that list.  We’re hoping that for each we can either close it, set an owner and target milestone, or set a NextAction date so that we know when to check back in.

I tested the original test cases.  TC1 and TC2 appear to now be working, but TC3 and TC4 are not.

Yosin@ is this Pri-2 for some target milestone in particular, or just Pri-3?

Comment 50 by yosin@chromium.org, Mar 27 2017
Components: -Blink>Editing
Status: Available
Comment 51 by yosin@chromium.org, Mar 27 2017
I propose candidate task of 2017/Q2 in DOM team.
I'll update once DOM team prioiritazation is done.

NextAction: 2017-04-25
Thank you!
Labels: Pri-3
Sign in to add a comment