DOM::Selection not protected against dom tree changes?

[Ken Kocienda]

In one very important respect, DOM::Selection is robust against its 
boundary nodes being removed from the DOM tree. The Selection class 
holds its boundary nodes in DOM::Position members, and the Position 
class holds a reference to its node. Consequently, there is no danger 
of a node being deleted if it is a boundary node of a selection and the 
node is removed from the document. You might well generate exceptions 
if you use such a "dangling" boundary point in a DOM function, but that 
is a much different problem than dereferencing a pointer to a freed 
object.

In one other important way, DOM::Selection is not robust against 
changes to the document, at least not in the way that DOM Ranges 
behave. I have always thought that it might be good to update Selection 
objects as the DOM is changed, but, as it has not yet presented 
problems as big as the ones I have been working on, I have never gotten 
around to doing the work. Yet, there are some foundation concepts in 
the Selection class for implementing this second kind of robustness. 
Take a look at the VisiblePosition class and Selection::validate. As 
for sending patches, I must be honest with you and say that I am 
severely pressed for time, and I will have very little opportunity to 
discuss or debate changes on this list. That said, I see no problem 
with sending the patches. Today, I will see about putting together a 
patch to bring you up to date.

- Ken


On Nov 26, 2004, at 9:15 AM, Leo Savernik wrote:


> Hello,
>
> In WebCore 146.1, all the old selection-specific stuff has been 
> replaced to make use of DOM::Selection.
>
> The problem I see with this implementation is that DOM::Selection 
> isn't robust against changes to the dom tree. As the principal 
> selection stays active between events, the boundary nodes may have 
> been deleted meanwhile -> dangling pointer in Selection -> crash.
>
> Did you take any countermeasures that protect WebCore from the above 
> scenario or are you planning on any such countermeasures?
>
> Btw, now that contenteditable has been unveiled for Safari, I ask you 
> to post patches against contenteditable/caret/selection stuff to this 
> list. Thank you.
>
> mfg
>  Leo
> _______________________________________________
> Khtml-devel at kde.org
> https://mail.kde.org/mailman/listinfo/khtml-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/khtml-devel/attachments/20041130/3b26c6d2/attachment.html