Opened 16 years ago
Closed 12 years ago
#2419 closed Bug (wontfix)
MoveToAncestorNode does not return the correct node
Reported by: | Henry Lyne | Owned by: | |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | General | Version: | FCKeditor 2.6.3 Beta |
Keywords: | Confirmed | Cc: |
Description
This seems to be a problem in IE7 and Safari. FCK.Selection.MoveToAncestorNode does not return the correct node, or SelectNode doesn't properly select.
Steps to recreate:
- Edit source and add
<div><p><b>bbbbbbb</b><br /><i>iiiiiiiiiii</i></p></div>
Switch back to the regular editor view.
- Select "iiiiiiiiiii".
- Run the following via the browser address bar:
javascript: alert(frames[0].FCK.Selection.SelectNode( frames[0].FCK.Selection.MoveToAncestorNode('DIV') )); javascript: alert(frames[0].FCK.InsertHtml('abcd'));
- View Source
- IE7 has the following:
<div><p><b>abcd</b><br /> </p></div>
- IE7 has the following:
- Safari has:
<div><p>abcd</p></div>
Output should look like:
abcd
Change History (6)
comment:1 Changed 16 years ago by
Milestone: | → FCKeditor 2.6.4 |
---|---|
Version: | FCKeditor 2.6.3 Beta → FCKeditor 2.6.3 |
comment:2 Changed 16 years ago by
Milestone: | FCKeditor 2.6.4 |
---|---|
Version: | FCKeditor 2.6.3 → FCKeditor 2.6.3 Beta |
comment:3 follow-up: 4 Changed 16 years ago by
comment:4 Changed 16 years ago by
Resolution: | → invalid |
---|---|
Status: | new → closed |
Replying to martinkou:
IE's selection model does not allow you to select the <div> node itself. (...)
So the real culprit here is that the browser doesn't remember the selection correctly, and the symptom appears in FCK.InsertHtml() because InsertHtml() depends on the browser's view on where the selection is.
comment:5 Changed 16 years ago by
Keywords: | Confirmed added |
---|---|
Resolution: | invalid |
Status: | closed → reopened |
There is actually a problem here. The fact is that the current implementation makes it hard to fix it. So this is a valid ticket.
We should investigate it more, and possibly close it as CantFix if we really find out that there is no other way for us with this.
comment:6 Changed 12 years ago by
Resolution: | → wontfix |
---|---|
Status: | reopened → closed |
There's no such a method like moveToAncestorNode and insertHtml has been completely rewritten, so I'm closing this issue as expired.
I'm not totally sure if this can be fixed. If you check the value returned by SelectNode() you'll find that it is indeed returning the <div> node.
SelectNode() isn't at fault here as well. IE's selection model does not allow you to select the <div> node itself - the reason is because it only uses caret positions to express a text selection. If you've used the DOMRange::selectNode() and DOMSelection.addRange() in Safari to select the the <div> node yourself, you'll notice document.execCommand('inserthtml' ...) will give you the same buggy result as us.
So the real culprit here is that the browser doesn't remember the selection correctly, and the symptom appears in FCK.InsertHtml() because InsertHtml() depends on the browser's view on where the selection is. If you happen to be writing a plugin to FCKeditor and want to replace entire block nodes, I recommend you to take a look at fckdomrange.js and use the FCKDomRange class in it instead.