Fix for crash when assigning document.body
Dirk Mueller
mueller at kde.org
Tue Oct 7 23:06:48 CEST 2003
On Monday 06 October 2003 23:11, Maciej Stachowiak wrote:
> Here's a patch for a regression my change caused
What is the regression about? testcase?
From what I can see from your diff I don't think you applied my patch
correctly. The "change return type to DocumentFragment" and the "use a
DocumentFragment f(fragment)" declaration was essential part of the patch,
and must not be optimized away.
> In fact, the object could be destroyed.
It can only be destroyed if its not in the document tree, correct. I mean,
thats the sole reason for the refcounting in the first place :-)
> caller. Fortunately I figured out how to pull this off by abusing
> setParent. But two wrongs don't make a right! :-)
I can understand that you're trying to show your deep understanding of the
refcounting sheme by using such a hack *evil grin*, but as you said, this is
an abuse, and hence the solution I used should be used instead. It also helps
against accidental memory leakage calling createContextualFragment without
tracking the return value. I think the minimal overhead of using the DOM
value wrapper DocumentFragment is more than justified. this method is not
exactly a cheap thing or a fast path anyway.
> P.S. If you'd like I can add a derefWithoutDestroying() or
> derefAndFloat() to TreeShared instead of the gross hack with
> setParent().
Hmm, no. I don't like
methodNamesThatSayWhatTheyDoExactlyInThatOrderInTheirUltraLongMethodName.
But you earned a cookie for introducing yet another meaning for the word
"float" in khtml ;-)
--
> Looking for a KDE-related EMail-Alias ? Get one at kdemail.net for FREE! <
More information about the Khtml-devel
mailing list