Move color chooser objects to the Oilpan heap.

Source/core/html/forms/ColorInputType.cpp

Index: Source/core/html/forms/ColorInputType.cpp
diff --git a/Source/core/html/forms/ColorInputType.cpp b/Source/core/html/forms/ColorInputType.cpp
index 3edd2dead5a76c7375d62458d16633f54add6907..54ab45aa143171d0906f7a8d4d7690a6eddcf2e9 100644
--- a/Source/core/html/forms/ColorInputType.cpp
+++ b/Source/core/html/forms/ColorInputType.cpp
@@ -82,7 +82,20 @@ PassRefPtrWillBeRawPtr<InputType> ColorInputType::create(HTMLInputElement& eleme
 
 ColorInputType::~ColorInputType()
 {
-    endColorChooser();
+    // The ColorChooser is responsible for 'ending' its own platform
+    // object when being destructed, but will not indirectly notify
+    // its ColorChooserClient when doing so (Oilpan friendly finalization.)

[haraken, 2014/10/07 08:27:35]

Hmm, this looks a bit weird. Can we either:

- make the ColorChooser send a notification to the clients so that the clients
can dispatch the event; or

- make the client observe the ColorChooser (using a weak member), register the
event dispatch in the weak processing, and actually dispatch the event in a
later event loop?

[sof, 2014/10/07 08:31:45]

That sounds needlessly complicated. Should we simply not dispatch the event?

[haraken, 2014/10/07 08:49:27]

I'm not sure. If it's OK to not dispatch the event, that should be the best
solution :)

tkent-san: Do you have any idea on this?

+    //
+    // So as to not miss out on anything, effect that notification locally.
+    if (m_chooser)
+        didEndChooser();

[haraken, 2014/10/07 08:27:35]

Is it safe to dispatch an event inside the destructor? I'm afraid it can lead to
script execution inside the destructor.

+}
+
+void ColorInputType::trace(Visitor* visitor)
+{
+    visitor->trace(m_chooser);
+    BaseClickableWithKeyInputType::trace(visitor);
+    ColorChooserClient::trace(visitor);
 }
 
 void ColorInputType::countUsage()