Oilpan: Remove guardRef and guardDeref from TreeScope.

Source/core/html/forms/BaseMultipleFieldsDateAndTimeInputType.cpp

Index: Source/core/html/forms/BaseMultipleFieldsDateAndTimeInputType.cpp
diff --git a/Source/core/html/forms/BaseMultipleFieldsDateAndTimeInputType.cpp b/Source/core/html/forms/BaseMultipleFieldsDateAndTimeInputType.cpp
index dd9b8033979a66dd8933d1951c384e7751a79aa2..80db48e9d08bb2d79af0d415fe1c071b40b58c8c 100644
--- a/Source/core/html/forms/BaseMultipleFieldsDateAndTimeInputType.cpp
+++ b/Source/core/html/forms/BaseMultipleFieldsDateAndTimeInputType.cpp
@@ -293,6 +293,7 @@ BaseMultipleFieldsDateAndTimeInputType::BaseMultipleFieldsDateAndTimeInputType(H
 
 BaseMultipleFieldsDateAndTimeInputType::~BaseMultipleFieldsDateAndTimeInputType()
 {
+#if !ENABLE(OILPAN)
     if (SpinButtonElement* element = spinButtonElement())
         element->removeSpinButtonOwner();
     if (ClearButtonElement* element = clearButtonElement())
@@ -301,6 +302,7 @@ BaseMultipleFieldsDateAndTimeInputType::~BaseMultipleFieldsDateAndTimeInputType(
         element->removeEditControlOwner();
     if (PickerIndicatorElement* element = pickerIndicatorElement())
         element->removePickerIndicatorOwner();

[haraken, 2014/04/25 05:21:42]

Related to the former comment, I'm not quite sure if removing this code is safe.

  Document --> BaseMultipleFieldsDateAndTimeInputType --> SpinButtonElement

As long as the TreeShared algorithm is working, I guess that it's possible that
Document and BaseMultipleFieldsDateAndTimeInputType die but SpinButtonElement is
still alive (because Node::m_parent is not yet a strong pointer). Then we still
need to clear the back pointer from SpinButtonElement to
BaseMultipleFieldsDateAndTimeInputType.

Probably I'm misunderstanding.

[Mads Ager (chromium), 2014/04/25 10:58:25]

That is a good question. This setup is interesting. These elements are in a
shadow subtree and are therefore not accessible from the outside (via
JavaScript) as far as I can tell, so I believe that these always die together.
In any case, that will be the end result, so I don't think I'll spent more time
thinking about this right now. Instead, one of the next changes here will make
sure that we trace parent pointers in these trees and at that point this is
definitely safe.

[tkent, 2014/04/25 12:51:16]

haraken is right.
This code block is necessary until the parent tracing.  We have several security
issues around here because a mouse event can hold a reference to a
SpinButtonElement, it dispatches input/change events, and an event handler
JavaScript code can remove everything except the SpinButtonElement.
I think it's ok to have temporarily problems until the parent tracing.

[Mads Ager (chromium), 2014/04/25 12:57:52]

Yeah, I filed a bug report on a SpinButton crash in connection with
NumberInputType because I noticed it in connection with this change. I'll move
right on to parent tracing after this change. :)

+#endif
 }
 
 String BaseMultipleFieldsDateAndTimeInputType::badInputText() const