<rdar://problem/31765379>
Created attachment 307915 [details] Patch
Created attachment 307916 [details] Minor renaming
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?
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.
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.
(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).
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!
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
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
Created attachment 307918 [details] Fix Win/GTK builds
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.
Committed <https://trac.webkit.org/changeset/215669/webkit>. WebRTC, RTL visual viewport, and audio-related test failures/flakiness encountered on EWS seem unrelated.