Bug 132306 – dataTransfer.types changes to null during execution of HTML drop event

• Component: DOM
• Status: NEW

[Owen Shaw]

Created attachment 230327 [details]
simplified test code

In an HTML drop event handler function, event.dataTransfer.types is initially non-null, but then changes to null, seemingly between lines of JavaScript.

The issue is sporadic, even in the simplified test code attached.  Furthermore, I have only reproduced this when dragging and dropping data from Chrome to Safari.

The attached test code sets up bare-minimum drop handling on document.body, and on drop loops 10 times, making a note each iteration of whether event.dataTransfer.types is null or non-null, and finally prints the results on the page.

1) Load attached HTML test page in Safari
2) Open Chrome and browse to any site
3) Drag text or image from Chrome to test page in Safari
4) Repeat as necessary to observe
    a) value can start as non-null and change to null
    b) the change can occur at different places on different runs

Repeated testing is key because the results vary from run to run.  Some runs will show the value as always null, others will show the value as never null, and some runs will show a changing value.

The test code is a bit contrived, but it helps catch the issue.  The code that started my investigation was essentially the following:

if (e.dataTransfer.types === null){
    return;
}
for (var i = 0, l = e.dataTransfer.types.length; i < l; ++i){
>> TypeError: 'null' is not an object (evaluating 'e.dataTransfer.types.length')

Which is one line saying .types is not null and then the next line throwing an error because .types is null.

Mac 10.9.2
Safari Version: 7.0.3 (9537.75.14)  (also tested in WebKit Nightly r167883)
Chrome Version: 34.0.1847.131

[Radar WebKit Bug Importer]

<rdar://problem/30299496>

[Geoffrey Garen]

I couldn't reproduce this bug using Safari Technology Preview Release 26. I tried a few times on a few different websites. Maybe it would help to specify the source website.

[Owen Shaw]

Looks like it may be fixed.  I just tried in Tech Preview 26 and can't reproduce the bug either.

Although it is still reproducible for me in Safari 10.1 (12603.1.30.0.34), so the fix must have been recent.  

The source site has never seemed important.  I just tried from google.com and nytimes.com today; both showed the bug in 10.1, and neither showed it in Preview 26.

Thanks for looking into it!

[Lucas Forschler]

Mass move bugs into the DOM component.