Bug 110682 - Deletion of selection in contenteditable node results in incorrect DOM ordering
Summary: Deletion of selection in contenteditable node results in incorrect DOM ordering
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: HTML Editing (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL: http://persistent.info/webkit/test-ca...
Keywords: HasReduction
Depends on:
Blocks:
 
Reported: 2013-02-22 22:02 PST by Mihai Parparita
Modified: 2013-02-23 15:16 PST (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mihai Parparita 2013-02-22 22:02:41 PST
Test case: http://persistent.info/webkit/test-cases/selection-deletion.html

1. Press the "Select '1. One'" button (or select the text "1. One" without the trailing newline)
2. Press the "execCommand('delete')" button (or press the delete key)

Expected result:

The "1. One" text is gone, but the contenteditable is otherwise unaffected, i.e.:
<empty line>
2. Two
3. Three

Actual result:

The latter two lines are combined into one, and the order is reversed:
<empty line>
3. Three2. Two

There appear to be several contributing factors in the test case:
- The lines all have "position: relative"
- There's a contenteditable=false "toolbar" div before before the first line
- There can't be any intervening whitespace in the DOM between the first two lines (see the lack of newline in the test case)

Bug 108987 may be related (in that it also involve contenteditable="false" elements)
Comment 1 Alexey Proskuryakov 2013-02-23 15:16:04 PST
Not a regression from Safari 6.