On Jun 6, 2012, at 6:27 PM, Darin Adler <da...@apple.com> wrote: > On Jun 6, 2012, at 6:14 PM, Kentaro Hara <hara...@chromium.org> wrote: > >> IMHO, (a) would be the best semantics. > > I agree, and I think that the specification actually does require this. > > The real issue here is how to fix this bug efficiently. I believe that Geoff > Garen has been contemplating this and also has a proposal for how to do it.
I vaguely recall that I originally implemented rule (b) for WebKit, and at the time I did it because: (1) The exact behavior in this case seemed unimportant; I couldn't find any sites depending on it, nor did it seem likely that they would. (2) It was the simplest apparent way to avoid leaking certain kinds of cycles that span GC and refcounting (I don't remember the details and this is likely no longer applicable)/ (3) It seemed that keeping ancestors alive would have the potential to hold large amounts of memory when much of it was unneeded. An even more extreme example of (3) would result if both parentNode and ownerDocument were strong references, and ownerDocument was made to be a real reference, not a self-only reference (at some point renamed to guardRef). Then keeping a single node that was in an isolated DOM subtree alive would also keep that whole document alive. I am not sure what other browsers do in this case. Of course, predictability might outweigh the potential memory use issues. Regards, Maciej
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
