Reviewed by Darin Adler.

        REGRESSION(r53287): drop event is not fired if dataTransfer.dropEffect is not explicitly set
        https://bugs.webkit.org/show_bug.cgi?id=36095

        Correct this test to cover the somewhat bizarre "correct" handling
        of undefined dropEffect

        * fast/events/drag-and-drop-expected.txt:
        * fast/events/drag-and-drop.html:
2010-03-14  Oliver Hunt  <oliver@apple.com>

        Reviewed by Darin Adler.

        REGRESSION(r53287): drop event is not fired if dataTransfer.dropEffect is not explicitly set
        https://bugs.webkit.org/show_bug.cgi?id=36095

        The issue here is that while dropEffect is meant to be initialized
        to "none", the behaviour of the drag is differs between dragEffect
        not being set and dragEffect being explicitly set to "none"

        This patch corrects this behaviour by making Clipboard distinguish
        between the initial "none" value of dropEffect and an explicit "none".
        This alone is insufficient for correct behaviour, we also need to
        resurrect the removed defaultOperationForDrag function, but we now
        use the function only when dragEffect is uninitialized.  There are a
        few tweaks to the behaviour of the defaultOperationForDrag as well
        to ensure exactly the same set of outcomes for all cases that we
        may hit it.

        * dom/Clipboard.cpp:
        (WebCore::Clipboard::Clipboard):
        (WebCore::dragOpFromIEOp):
        (WebCore::Clipboard::destinationOperation):
        * dom/Clipboard.h:
        (WebCore::Clipboard::dropEffect):
        (WebCore::Clipboard::dropEffectIsUninitialized):
        * page/DragController.cpp:
        (WebCore::defaultOperationForDrag):
        (WebCore::DragController::tryDHTMLDrag):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@55977 268f45cc-cd09-0410-ab3c-d52691b4dbfc