549555 - [10.6] "New TextEdit Window Containing Selection" Services Menu item produces a TextEdit error message

Status: NEW

(Core :: Widget: Cocoa, defect, P3)

Description

[philippe (part-time)]

Running the "New TextEdit Window Containing Selection" Services Menu item from within Minefield (with text selected in the content area) produces a TextEdit error message.

1. select some text in a web page
2. From the services menu run: New TextEdit Window Containing Selection

AR: TextEdit jumps in the dock an shows an error message

[quote]
There might be an internal error or a performance problem, or the source application may be providing text of invalid type in the service request. Please try the operation a second time. If that doesn’t work, copy/paste the selection into TextEdit.
[/quote]

ER: TextEdit opens a new rtf doc with the selected text.

This works fine on 10.5.8

---
oddly, whe the webpage is an xhtml document (application/XHTML+XML) the service 'works', that is, it opens a TE document, but text-encoding is all over the place - anything but ascii is br0ken.

two sample documents: http://dev.l-c-n.com/camino/services/

That service item also works correctly with Camino 2.0.2 on 10.6 (although it only produce plain text documents in Textedit. Experimental builds of Camino using Gecko 1.9.2 fail the same as Gecko 1.9.3a / Minefield builds.

Comment 1

[philippe (part-time)]

Attachment: test document - text/html

Comment 2

[philippe (part-time)]

Attachment: test document - application/xhtml+xml

Comment 3

[Tom Dyas]

I can confirm the problem with TextEdit. I also tried New Email with Selection," and Mail.app appeared to accept the selected text without a problem. TextEdit may have a problem with the way in which the HTML form of the selection is generated or encoded.  The code that generates this HTML is nsClipboard::WrapHtmlForSystemPasteboard in widget/src/cocoa/nsClipboard.mm.

Comment 4

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #3)
> TextEdit may have a problem with the way in which the HTML form of the
> selection is generated or encoded.  The code that generates this HTML is
> nsClipboard::WrapHtmlForSystemPasteboard in widget/src/cocoa/nsClipboard.mm.

I had the same thought, but isn't that the same HTML wrapping code used by copy/paste, which isn't broken AIUI? AFAICS, that's the stuff added in bug 466599 to fix copy/paste and drag-drop issues.

Comment 5

[Tom Dyas]

(In reply to comment #4)
> (In reply to comment #3)
> > TextEdit may have a problem with the way in which the HTML form of the
> > selection is generated or encoded.  The code that generates this HTML is
> > nsClipboard::WrapHtmlForSystemPasteboard in widget/src/cocoa/nsClipboard.mm.
> 
> I had the same thought, but isn't that the same HTML wrapping code used by
> copy/paste, which isn't broken AIUI? AFAICS, that's the stuff added in bug
> 466599 to fix copy/paste and drag-drop issues.

That appears to be the case.  Mail.app accepts the wrapper HTML string just fine while TextEdit does not, which leads me to believe the problem is with the way TextEdit interprets the HTML data. The services code intentionally uses the same helpers as the clipboard code so there should be no difference in the pasteboard contents.

As a side note and interestingly enough, Safari puts RTF and not HTML on the services pasteboard.

Comment 6

[Tom Dyas]

(In reply to comment #0)
> oddly, whe the webpage is an xhtml document (application/XHTML+XML) the service
> 'works', that is, it opens a TE document, but text-encoding is all over the
> place - anything but ascii is br0ken.

After a little more digging, the XHTML document only "works" because Firefox is not putting HTML for it on the pasteboard, only a plain text string.  This might be a separate bug in Firefox. (I am using my "Pasteboard Inspector" testing service to see the pasteboard contents.)

Comment 7

[Timothy [:timothy.b]]

We seem to be experiencing this same failure with the macOS Service "New TextEdit Window Containing Selection" in Firefox 81 on macOS 10.13.6.