Bug 82497 – REGRESSION: editing/pasteboard/dataTransfer-setData-getData.html fails on Mac platforms

• Component: HTML Editing
• Status: RESOLVED FIXED

[Enrica Casucci]

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.

[Radar WebKit Bug Importer]

<rdar://problem/11140334>

[Enrica Casucci]

Created attachment 134367 [details]
Patch

[Brady Eidson]

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!  :)

[Brady Eidson]

And also - did TestWebKitAPI run successfully with this change?

[Enrica Casucci]

Created attachment 134373 [details]
Patch2

New patch that addresses reviewer's comments.

[Enrica Casucci]

http://trac.webkit.org/changeset/112473

[Alexey Proskuryakov]

Isn't this the same as bug 81125 and its associated radar?

[Brady Eidson]

(In reply to comment #7)
> Isn't this the same as bug 81125 and its associated radar?

Seems almost certain that it is