Closed
Bug 460740
Opened 16 years ago
Closed 13 years ago
[contenteditable][list-item] invalid results when pressing ENTER inside 1. a contenteditable LI or 2. a contenteditable element inside a LI or 3. a contenteditable element inside a block element inside a LI
Categories
(Core :: DOM: Editor, defect)
Core
DOM: Editor
Tracking
()
RESOLVED
FIXED
mozilla8
People
(Reporter: dpopa, Assigned: kaze)
References
Details
(Keywords: testcase)
Attachments
(4 files, 3 obsolete files)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3 [contenteditable] invalid results when pressing ENTER inside 1. a contenteditable LI (<li contenteditable="true">) 2. a contenteditable element inside a LI (<li><div contenteditable="true">) 3. a contenteditable element inside a block element inside a LI(<li><div><div contenteditable="true">) Editing should be contained inside the contenteditable element. Actual results for each case: 1. New contenteditable LI gets created. 2. New contenteditable element gets created. 3. Nothing happens. Expected results: editing takes place inside the editanle element and: 1. Split selection with a BR. 2. same as 1 3. same as 1 The described expected results are debatable. Reproducible: Always
I have also encountered this bug in firefox 3.0.8 on both mac and windows. Any way I attempt to structure the document, the same result happens. This does not occur in any other browser.
Comment 5•13 years ago
|
||
Bug 647760 claims nothing happens when pressing Enter in the second case on Windows 7.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: testcase
Summary: [contenteditable] invalid results when pressing ENTER inside 1. a contenteditable LI or 2. a contenteditable element inside a LI or 3. a contenteditable element inside a block element inside a LI → [contenteditable][list-item] invalid results when pressing ENTER inside 1. a contenteditable LI or 2. a contenteditable element inside a LI or 3. a contenteditable element inside a block element inside a LI
(In reply to comment #5) > Bug 647760 claims nothing happens when pressing Enter in the second case > on Windows 7. Nothing happens indeed in the second case but only when the DIV is empty (no contents in it) as it's the case in bug 647760: <ul><li><div contentEditable=true></div></li></ul> So bug 647760 is not actually a duplicate of this but in fact another case for this bug.
Updated•13 years ago
|
Assignee: nobody → ehsan
Whiteboard: [post-2.0]
Comment 7•13 years ago
|
||
I guess the reason behind this bug is missing to check for the active editing host somewhere...
Assignee: ehsan → kaze
Assignee | ||
Comment 8•13 years ago
|
||
Confirmed. Here are two another typical cases where [Enter] should create a <br>: <p contenteditable> Editable P: [Enter] creates another editable P. </p> <p> <span contenteditable> Editable SPAN in a P: [Enter] does nothing. </span> </p> I’ll have a look at `nsHTMLEditRules::WillInsertBreak' ASAP.
Assignee | ||
Comment 9•13 years ago
|
||
Here's a testcase that adds three tests involving paragraphs.
Assignee | ||
Comment 10•13 years ago
|
||
Here’s a quick fix, I still have to write the tests.
Comment 11•13 years ago
|
||
Couldn't you use IsNodeInActiveEditor?
Assignee | ||
Comment 12•13 years ago
|
||
(In reply to comment #11) > Couldn't you use IsNodeInActiveEditor? I could. As IsNodeInActiveEditor(aNode) returns true if `aNode' is the active editing host, we still have to call GetActiveEditingHost() to make sure that `aNode' is not the editing host itself to avoid the duplication of an editable paragraph / listitem / header. Since nsEditorUtils::IsDescendentOf(aNode, aParent) returns false if aNode==aParent, it seems a little simpler to use IsDescendentOf + GetActiveEditingHost imho. If you prefer using IsNodeInActiveEditor please let me know and I’ll adapt this patch.
Assignee | ||
Updated•13 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 13•13 years ago
|
||
Same patch, with tests.
Attachment #548213 -
Attachment is obsolete: true
Attachment #548426 -
Flags: review?
Comment 14•13 years ago
|
||
(In reply to comment #12) > (In reply to comment #11) > > Couldn't you use IsNodeInActiveEditor? > > I could. > > As IsNodeInActiveEditor(aNode) returns true if `aNode' is the active editing > host, we still have to call GetActiveEditingHost() to make sure that `aNode' > is not the editing host itself to avoid the duplication of an editable > paragraph / listitem / header. > > Since nsEditorUtils::IsDescendentOf(aNode, aParent) returns false if > aNode==aParent, it seems a little simpler to use IsDescendentOf + > GetActiveEditingHost imho. If you prefer using IsNodeInActiveEditor please > let me know and I’ll adapt this patch. No, nevermind then!
Comment 15•13 years ago
|
||
Comment on attachment 548426 [details] [diff] [review] patch proposal The patch looks good, but I think we should also test the behavior of pressing enter at the beginning and in the middle of the text for each element.
Attachment #548426 -
Flags: review?
Assignee | ||
Comment 16•13 years ago
|
||
Same patch, updated tests.
Attachment #548426 -
Attachment is obsolete: true
Attachment #548459 -
Flags: review?(ehsan)
Assignee | ||
Comment 17•13 years ago
|
||
s/kimpleTest/SimpleTest/ sorry for the typo :-s
Attachment #548459 -
Attachment is obsolete: true
Attachment #548523 -
Flags: review?(ehsan)
Attachment #548459 -
Flags: review?(ehsan)
Updated•13 years ago
|
Attachment #548523 -
Flags: review?(ehsan) → review+
Updated•13 years ago
|
Whiteboard: [post-2.0]
Comment 18•13 years ago
|
||
Pushed to mozilla-inbound.
Comment 19•13 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/d035ba160ce0
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla8
You need to log in
before you can comment on or make changes to this bug.
Description
•