Bug 8276 – REGRESSION (NativeTextField): Pasting a Finder item into a text field results in a file: URL being pasted instead of just the file name

• Status: RESOLVED
• Resolution: FIXED
• Component: Forms

Steps to reproduce:
1) Select an item in the Finder
2) Choose Edit > Copy "<name of selected item>"
3) In Safari, go to http://www.google.com/
4) Choose Edit > Paste

Expected results:
Only the name of the item copied from the finder should be pasted into the field.

Actual results:
A file: URL for the copied item is pasted into the field.

[Adele Peterson]

While this is a native text field regression, we think the symptom is mild, so we're moving it to P2.

Created attachment 7642 [details]
Paste as plain text when targeting a text field

-[WebHTMLView _plainTextFromPasteboard:] is based on observing the behavior of AppKit text fields. This patch also addresses bug 8283.

[Darin Adler]

Comment on attachment 7642 [details]
Paste as plain text when targeting a text field

Looks fine. I'm not sure about the part about enabling the pasteAsRichText: selector, but frankly I don't understand the value of that selector anyway, nor do I think it's used in any common case.

r=me

Comment on attachment 7642 [details]
Paste as plain text when targeting a text field

Thanks to Justin I've noticed that this patch makes dragging a link into a text field result in the link's text being pasted instead of the URL. This is actually behavior that would be nice to have in rich text (pasting an anchor) but not in fields.

(In reply to comment #4)
> [T]his patch makes dragging a link into a text
> field result in the link's text being pasted instead of the URL.

I was wrong (again!), it doesn't, since the NSStringPboardType contains the URL in that case. So I think the patch is fine, but I don't know how to make a test for it.

Created attachment 7806 [details]
Same code patch, with a change log and a manual test for this bug and bug 8283

Created attachment 7808 [details]
Contents of resources/plain-text-paste

[Darin Adler]

Comment on attachment 7806 [details]
Same code patch, with a change log and a manual test for this bug and bug 8283

r=me again

The resources for the test weren't checked in properly. Their resource forks and Finder metadata need to be preserved for the test to work. I think the right way to do it is to use /Developer/Tools/SplitForks on the directory and then check in the AppleDouble pairs.

[Mark Rowe (bdash)]

Fixed in r16827.