This is very likely a regression caused by http://trac.webkit.org/changeset/111267. This revision fixed the way data is written to the pasteboard for NSURLPboardType. We now need to fix how it is read from the pasteboard in that format.
<rdar://problem/11140334>
Created attachment 134367 [details] Patch
Comment on attachment 134367 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=134367&action=review > Source/WebCore/platform/mac/ClipboardMac.mm:207 > // Fallback to NSURLPboardType (which is a single URL) > if (availableTypes.contains(String(NSURLPboardType))) { > - platformStrategies()->pasteboardStrategy()->getPathnamesForType(absoluteURLs, String(NSURLPboardType), pasteboardName); > + absoluteURLs.append(platformStrategies()->pasteboardStrategy()->stringForType(String(NSURLPboardType), pasteboardName)); > if (!absoluteURLs.isEmpty()) > return absoluteURLs; It seems that the old code - using getPathnamesForType() - could return anywhere from 0 to many URLs so the absoluteURLs.isEmpty() check was relevant. But the comment suggests that NSURLPboardType should only ever be 1 URL. And - in fact - this new code can only ever return exactly 1 URL. Nuke that unnecessary !absoluteURLs.isEmpty() check! :)
And also - did TestWebKitAPI run successfully with this change?
Created attachment 134373 [details] Patch2 New patch that addresses reviewer's comments.
http://trac.webkit.org/changeset/112473
Isn't this the same as bug 81125 and its associated radar?
(In reply to comment #7) > Isn't this the same as bug 81125 and its associated radar? Seems almost certain that it is