In contenteditable mode, "delete" key between 2 different elements doesn't work anymore

RESOLVED WORKSFORME

Status

()

Core
Editor
RESOLVED WORKSFORME
8 years ago
2 years ago

People

(Reporter: Anca Luca, Unassigned)

Tracking

({regression})

Trunk
regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

8 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.3) Gecko/20090910 Ubuntu/9.04 (jaunty) Shiretoko/3.5.3
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.3) Gecko/20090910 Ubuntu/9.04 (jaunty) Shiretoko/3.5.3

When the content of a contenteditable element is, for example:
<p>foo</p><p>bar</p>
and the cursor is placed at the end of "foo", hitting delete key has no effect when it should result in moving "bar" to the same paragraph, such as:
<p>foobar</p>.
Note that backspace at the beginning of "bar" works perfectly fine and does the expected merge.

Reproducible: Always

Steps to Reproduce:
In a local file or in the editor demo at http://www.mozilla.org/editor/midasdemo/
1. set the following html content: <div contenteditable="true"><p>foo</p><p>bar</p></div>
2. open file in browser or switch to editing and place the caret at the end of "foo" 
3. hit the delete key
Actual Results:  
nothing happens

Expected Results:  
"bar" should move on the same line as "foo" and the html code should now become:
<div contenteditable="true"><p>foobar</p></div>

This reproduces for all kind of elements, not only paragraphs (2 consecutive lists for example are not merged on delete in the first one for example, deleting at the end of a list followed by a paragraph does not move the text in the paragraph to the list item, etc), while backspace at the beginning of the next item works correctly.

I encountered the bug in the 3.5 Firefox version, and it doesn't reproduce on Firefox 2.0 nor 3.0.
(Reporter)

Updated

8 years ago
Hardware: x86 → All
I couldn't reproduce the problem with the steps you provided, maybe it's fixed on trunk? Could you try to reproduce the problem with a nightly build from here:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/

It sounds like it's the same as bug 502259, which is fixed on trunk, in the upcoming FF3.6 beta and in the upcoming FF3.5.4.
(Reporter)

Comment 2

8 years ago
Hi Chris, 

indeed it's a duplicate of bug 502259 (sorry for the duplicate -- I did search it I just didn't find it) which I cannot reproduce on the nightly build you indicated. 

However, the usecase discussed in comment #34 from that bug, *is* indeed a regression from 3.0. At least my 3.0.14 on ubuntu (installed from the ubuntu repositories) does handle the delete at the end of the list item ("two") correctly. Also, the behaviour between a list and a paragraph, for example, is a regression (delete at the end of a <p> before a <ul> -- 3.0 used to pull up the first list item content in the paragraph, nightly 3.7a1pre you indicated just moves the caret in the list and subsequent deletes remove the content in the list).

Should I move this discussion in the comments for 502259?
(Reporter)

Comment 3

8 years ago
Created attachment 403883 [details]
paragraphs and lists test cases
(Reporter)

Updated

8 years ago
Attachment #403883 - Attachment description: added test file for the cases discussed in comment#2 → paragraphs and lists test cases
(Reporter)

Comment 4

8 years ago
forgot to mention, the cases in the file should be studied for hitting delete at the end of "foo".

Comment 5

8 years ago
confirmed on FF 3.5.4
Status: UNCONFIRMED → NEW
Depends on: 507936
Ever confirmed: true
Version: unspecified → Trunk

Updated

8 years ago
Keywords: regression

Comment 6

2 years ago
User Agent 	Mozilla/5.0 (X11; Linux x86_64; rv:49.0) Gecko/20100101 Firefox/49.0
Build ID 	20160526083057

Works for me on latest Nightly (49.0a1). I tested on Ubuntu 15.04 and Windows7. If anyone can still reproduce the issue on a current build fell free to reopen the bug.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.