Oilpan: make DocumentFragment a heap allocated object.

Source/core/dom/DocumentFragment.idl

Index: Source/core/dom/DocumentFragment.idl
diff --git a/Source/core/dom/DocumentFragment.idl b/Source/core/dom/DocumentFragment.idl
index 005032a254e262464d636cccd1c2edcc3782e932..343f805670e70e7af8ef65148175fe6cfb7fa3ce 100644
--- a/Source/core/dom/DocumentFragment.idl
+++ b/Source/core/dom/DocumentFragment.idl
@@ -20,6 +20,7 @@
 [
     Constructor,
     ConstructorCallWith=Document,
+    WillBeGarbageCollected,

[haraken, 2014/05/18 22:07:36]

What happens if you make Node [WillBeGarbageCollected]?

There are a lot of overloaded methods (e.g., toV8, wrap etc) and I'm not sure if
it's safe to make only a part of the Node hierarchy [WillBeGarbageCollected]. To
avoid the confusion, we might want to make Node [WillBeGarbageCollected] first,
instead of making some sub-Node [WillBeGarbageCollected].

[sof, 2014/05/20 09:19:55]

That will trigger some amount of work, moving various RefPtrs over Nodes and
Elements over. I've not taken it on here, but could do that separately, before
or after?

[haraken, 2014/05/20 09:32:32]

I checked the binding code and confirmed that adding [WillBeGarbageCollected] to
a part of the hierarchy won't confuse overload resolution. (We're already doing
that for DOM objects that inherit from EventTarget.) So after is OK, but the
eariler, the better :)

Shall we add a FIXME and mention that the [WillBeGarbageCollected] should be
removed.

[sof, 2014/05/20 13:15:04]

ok, thanks - added the FIXME.

 ] interface DocumentFragment : Node {
     // NonElementParentNode API.
     Element getElementById(DOMString elementId);