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