Bug 171177 – File inputs only accept UTI types that can be inserted into contenteditable areas when dropping

• Status: RESOLVED
• Resolution: FIXED
• Component: WebCore Misc.

[Wenson Hsieh]

<rdar://problem/31765379>

[Wenson Hsieh]

Created attachment 307915 [details]
Patch

[Wenson Hsieh]

Created attachment 307916 [details]
Minor renaming

[Andy Estes]

Comment on attachment 307916 [details]
Minor renaming

This makes dragging incompatible content a little more expensive now that there's always a hit test in canProcessDrag(). Are you concerned about that?

[Wenson Hsieh]

Thanks for taking a look Andy!

(In reply to Andy Estes from comment #3)
> Comment on attachment 307916 [details]
> Minor renaming
> 
> This makes dragging incompatible content a little more expensive now that
> there's always a hit test in canProcessDrag(). Are you concerned about that?

This is true. But I think in the vast majority of cases, there is compatible content in the pasteboard, and even in the cases where there isn't compatible content, we will end up incurring the same cost as if there were compatible content, which AFAIK isn't an issue currently.

[Andy Estes]

Comment on attachment 307916 [details]
Minor renaming

Actually, can't you just change DragData::containsCompatibleContent() to check for kUTTypeContent? That would avoid the extra hit testing it seems.

[Wenson Hsieh]

(In reply to Andy Estes from comment #5)
> Comment on attachment 307916 [details]
> Minor renaming
> 
> Actually, can't you just change DragData::containsCompatibleContent() to
> check for kUTTypeContent? That would avoid the extra hit testing it seems.

That would work when dragging over file inputs, but that would produce incorrect behavior when dropping into an editable area (for example, a JSON file should not be allowed to drop into a contenteditable).

[Andy Estes]

Comment on attachment 307916 [details]
Minor renaming

I talked to Wenson on IRC and he explained why we can't check for a UTI in containsCompatibleContent() without hit-testing first. Thanks, Wenson!

[Build Bot]

Comment on attachment 307916 [details]
Minor renaming

Attachment 307916 [details] did not pass mac-debug-ews (mac):
Output: http://webkit-queues.webkit.org/results/3586948

New failing tests:
webrtc/datachannel/basic.html

[Build Bot]

Created attachment 307917 [details]
Archive of layout-test-results from ews112 for mac-elcapitan

The attached test failures were seen while running run-webkit-tests on the mac-debug-ews.
Bot: ews112  Port: mac-elcapitan  Platform: Mac OS X 10.11.6

[Wenson Hsieh]

Created attachment 307918 [details]
Fix Win/GTK builds

[Build Bot]

Attachment 307918 [details] did not pass style-queue:


ERROR: Source/WebCore/platform/gtk/DragDataGtk.cpp:0:  No copyright message found.  You should have a line: "Copyright [year] <Copyright Owner>"  [legal/copyright] [5]
Total errors found: 1 in 8 files


If any of these errors are false positives, please file a bug against check-webkit-style.

[Wenson Hsieh]

Committed <https://trac.webkit.org/changeset/215669/webkit>. WebRTC, RTL visual viewport, and audio-related test failures/flakiness encountered on EWS seem unrelated.