Closed Bug 428096 Opened 16 years ago Closed 16 years ago

Clipboard and drag-and-drop don't interoperate with formatted text (e.g. HTML) on OS X

Categories

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

All
macOS
defect

Tracking

()

RESOLVED FIXED
mozilla1.9.1b2

People

(Reporter: avarma, Assigned: avarma)

References

(Depends on 2 open bugs)

Details

Attachments

(1 file, 7 obsolete files)

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008040817 Minefield/3.0pre
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008040817 Minefield/3.0pre

This bug/enhancement involves multiple components:

  (1) If the clipboard contains HTML content, it is ignored when pasted into a rich text editing widget (e.g. http://www.kevinroth.com/rte/demo.htm).  That is, only the plain-text representation of the clipboard content is pasted-in.

  (2) Similarly, if HTML content from another application is dragged to a Firefox rich text editing widget, only the plain-text representation of the content is pasted-in.

  (3) If selected rich content from Firefox is copied out and pasted into another application that accepts HTML content, such as TextEdit (or any NSTextView-based widget, I believe), a HTML flavor is not included, and as a result the pasted content is plain-text.

  (4) Similarly, if selected rich content from Firefox is dragged over to another application's widget that accepts HTML content, a HTML flavor is not included.

It should be noted, however, that in the "pasting-into-firefox" situation, native NSTextView widgets in OS X do not export rich content in HTML--they only export such content in RTF.  In fact, I haven't yet seen any applications that actually export the HTML flavor other than one I'm currently working on (http://code.google.com/p/enso), and for which support for this feature is highly desirable.

That said, however, native NSTextView widgets *do* read from pasteboards with the HTML flavor, and as such the "pasting-content-from-firefox" situation would greatly benefit from this relatively easy-to-implement enhancement.


Reproducible: Always

Steps to Reproduce:
To reproduce (1), execute the following Python script (make sure you have PyObjC installed):

  import AppKit

  pb = AppKit.NSPasteboard.generalPasteboard()
  pb.declareTypes_owner_( [AppKit.NSStringPboardType,
                           AppKit.NSHTMLPboardType],
                          None )
  pb.setString_forType_( "<p>you <i>do</i> have support for HTML content.</p>",
                         AppKit.NSHTMLPboardType )
  pb.setString_forType_( "you do not have support for HTML content.",
                         AppKit.NSStringPboardType )

Then, go to a rich text editing widget in Firefox and paste the clipboard contents into it.

I actually have no current way to test (2).

For (3), just select any richly-formatted text from a web page in Firefox, copy it to the clipboard, open TextEdit, and paste the clipboard contents.

For (4), drag any richly-formatted text from a web page in Firefox to a TextEdit document.

Actual Results:  
For (1), the text "you do not have support for HTML content." appears in the rich text edit field in Firefox.

For (3) and (4), only the plaintext representation of the clipboard/selection makes its way into TextEdit.


Expected Results:  
For (1), the HTML-formatted text "you do have support for HTML content" should be pasted into the rich text edit field, and the word "do" should be in italics.

For (3) and (4), the full rich-text representation of the clipboard/selection, including hyperlinks, should make its way into TextEdit.
A few notes about this:

* As noted in the original ticket, I know of no current way to actually test whether (2) is fixed, or whether (2) actually even exists based on anything other than examination of the code.  This strikes me as a little suspicious, but I thought it would be equally unusual to not apply the enhancement to all applicable areas of the code.

* There is a bit of a violation of DRY in this patch that I don't like--namely, the simple logic to map the iTransferable mime-type name to the AppKit equivalent is repeated 4 times, which I don't like.  However, I'm not entirely sure what the best course is to consolidate this logic; the hacky way to do it would be to create a macro; it may be more appropriate to create a new function to do this in an existing file or a new "pasteboard utilities" module, I'm not sure.  I figure I'd rather just submit a suboptimal patch and get feedback rather than try to implement the best-possible patch from the beginning.
Flags: wanted-next+
This is bug 79864, right, or at least most of it (missing the non-HTML rich text support)?  Definitely not an enhancement in that case ;)

Since Josh gave it a wanted flag, confirming, assigning, and making it block 79864.
Assignee: joshmoz → avarma
Severity: enhancement → normal
Status: UNCONFIRMED → NEW
Ever confirmed: true
Please regenerate the patch using this diff format, which is standard for Mozilla:

diff -p -U 8
Sorry about that--the one I just attached should be okay.
Attachment #314748 - Attachment is patch: true
Attachment #314748 - Attachment mime type: application/octet-stream → text/plain
In nsChildView.mm we do this:

  [self registerForDraggedTypes:[NSArray arrayWithObjects:NSFilenamesPboardType,
                                                          NSStringPboardType,
                                                          NSURLPboardType,
                                                          NSFilesPromisePboardType,
                                                          kWildcardPboardType,
                                                          kCorePboardType_url,
                                                          kCorePboardType_urld,
                                                          kCorePboardType_urln,
                                                          nil]];

If you don't add the NSHTMLPboardType type to that list, we won't be able to receive HTML from other apps via the native clipboard. I'm guessing you didn't notice because Firefox was the drag originator in your tests and the drag succeeded completely via internal data structures (after being accepted because of the kWildcardPboardType part of the list above). See these comments in nsClipboard.mm:

  // If we were the last ones to put something on the pasteboard, then just use the cached
  // transferable. Otherwise clear it because it isn't relevant any more.

...

  // at this point we can't satisfy the request from cache data so let's look
  // for things other people put on the system clipboard
Ah, sorry about that.  I think, though, that the reason I didn't notice this originally was because it actually falls under part (2) of my enhancement, which, as I mentioned in the original bug, I was never able to actually manually test because I don't know of any applications which export HTML content for dragging.

I am frankly a bit disappointed that Apple's native widgets only export in RTF and not HTML, though.  For us to support the importing of data via the clipboard/drag-and-drop in a way that's truly helpful, it seems like we'll have to have some sort of RTF->HTML conversion going on... Either that or support RTF natively within the core, both of which sound Hard. :(

In any case, I'll submit the patch with your fix.
Attachment #314748 - Attachment is obsolete: true
Attachment #314889 - Attachment mime type: application/octet-stream → text/plain
Attachment #314889 - Attachment is patch: true
Comment on attachment 314889 [details] [diff] [review]
Patch with Josh's registerForDraggedTypes: fix included.

-    if (!strcmp(aFlavorList[i], kUnicodeMime)) {
-      NSString* availableType = [generalPBoard availableTypeFromArray:[NSArray arrayWithObject:NSStringPboardType]];
-      if (availableType && [availableType isEqualToString:NSStringPboardType]) {
+    if (!strcmp(aFlavorList[i], kUnicodeMime) ||
+        !strcmp(aFlavorList[i], kHTMLMime)) {
+      NSString* availableType = [generalPBoard availableTypeFromArray:[NSArray arrayWithObjects:NSStringPboardType, NSHTMLPboardType, nil]];
+      if (availableType) {

This logic seems incorrect. If someone calls "HasDataMatchingFlavors" and just asks for kHTMLMime, we'll end up returning PR_TRUE even if the native clipboard only has NSStringPboardType.

-    if (flavorStr.EqualsLiteral(kUnicodeMime)) {
+    if (flavorStr.EqualsLiteral(kUnicodeMime) ||
+        flavorStr.EqualsLiteral(kHTMLMime)) {
+      const NSString *pboardType;
...
-      [pasteboardOutputDict setObject:nativeString forKey:NSStringPboardType];
+      if (flavorStr.EqualsLiteral(kUnicodeMime))
+        pboardType = NSStringPboardType;
+      else
+        pboardType = NSHTMLPboardType;
+      [pasteboardOutputDict setObject:nativeString forKey:pboardType];

Please declare "pboardType" right before use, above the "if/else".
We should take this patch for the next major version of Gecko. Too late for Gecko 1.9.
Ack, sorry about the incorrect logic--I'd based that off the image-detection code just below it, which upon closer inspection was a bad idea.

The version I'm uploading now should fix those two things.
Attachment #314889 - Attachment is obsolete: true
Attachment #315217 - Flags: review?(joshmoz)
(In reply to comment #10)
> We should take this patch for the next major version of Gecko. Too late for
> Gecko 1.9.

Why the next major version? Because of the API change?
Er, there's no API change, sorry - so my question is then, why major Gecko version?
Because this is an enhancement, not a blocker, and I thought we were getting serious about only taking what is necessary for the release. This isn't a high risk patch but it isn't minimal risk either.
I understand comment 14 (though enh vs. bug is debatable, as this is inconsistent UI behaviour with other OSX applications, and drag-and-drop is a pretty basic function in computers these days) and I certainly agree that if it's risky we shouldn't be trying to cram it it so close to a release.

You stated "major Gecko version" though, which to me implies Moz2 instead of Gecko 1.9.1 or even 1.9.0.1, and I'm trying to understand what in this patch is that risky. We seem to be adding a copy object type that's well supported by OSX, so I'm trying to get a sense of where the risk is, and what sort of mitigation (in terms of tests, bake time, beta exposure, etc) we'd need to do in order to get comfortable.
In most cases a 50 line change to core widgets comes with non-trivial risk regardless of what system it applies to. In my previous comment I meant Gecko 1.9.1, but after some thought I guess 1.9.0.1 is fine. I just don't want this for 1.9.0.0. We need to ship and this isn't a regression whether it is a bug or an enhancement.
Flags: wanted-next+ → wanted1.9.0.x+
Comment on attachment 315217 [details] [diff] [review]
Fixes the latest two problems w/ the patch.

Looks good, thanks!
Attachment #315217 - Flags: review?(joshmoz) → review+
Version: unspecified → Trunk
Hardware: Macintosh → All
Status: NEW → ASSIGNED
Priority: -- → P2
Hi,

I see the patches, but how do I install them in Firefox 3?
I put in a bug report (Bug 442510), and they said that this one was the same problem, but I can't seem to find a way to install this supposed patch to fix my issue.

Any help would be greatly appreciated.
(In reply to comment #21)
You can't "install" a patch.  You can apply a patch to the source code for Gecko and rebuild Firefox using the changes made by the patch. Or, you can wait for it to make it's way into a nightly (unsupported and only lightly tested) or official build depending on how much risk you are willing to accept and how adventurous you are.

The bug will be marked fixed if/when the patch is checked in on the trunk (development repository).
The keyword fixed1.9.0.x will be added if/when the patch is checked in on the 1.9.0.x (3.0.x) branch where x is the number of the corresponding release.  Bug state and keywords may also become verified which implies fixed.

If you'd like to build Firefox with the patch yourself see http://developer.mozilla.org/en/docs/Build_Documentation .  If you need additional help post at http://forums.mozillazine.org/viewforum.php?f=27 or log on to the #firefox channel on the irc.mozilla.org IRC server.  <https://www.mibbit.com/?server=irc.mozilla.org&channel=%23firefox&nick=chrishall>
Problem remains in firefox 3.0.1 -- looking eagerly forward to the patch being checked in.
It doesn't look like Josh found any problems in his review; is there something else blocking requesting sr on the patch?
Sorry, the blocker on this one right now is me.  Josh wanted me to give the code a final sweep and make sure it works with the current trunk before submitting it for final review, but I'm not a core Mozilla developer and have had some trouble building an unpatched mozilla-central since it moved to HG (I don't think the problem is with HG though--it's a strange linker error that wasn't happening before).  As soon as I get that resolved I'll move forward, but in the meantime, if anyone else would like to take a stab at getting this patch to run on the trunk to verify that it still works, it would certainly be appreciated.
(In reply to comment #25)
> had some trouble building an unpatched mozilla-central since it moved to HG (I
> don't think the problem is with HG though--it's a strange linker error that
> wasn't happening before).  As soon as I get that resolved I'll move forward,

Building from mozilla-central with OS X 10.5 works for me. If you need help, you can drop me a mail with the errors. Perhaps I can help.
Well I just tried 3.1 Alpha 1, and Copy/Paste STILL doesn't work with formatted text yet, so I am guessing that it still hasn't been fully tested/implemented.
(In reply to comment #27)
> Well I just tried 3.1 Alpha 1, and Copy/Paste STILL doesn't work with formatted
> text yet, so I am guessing that it still hasn't been fully tested/implemented.

This bug is still open, so there's no reason to expect formatted copy/paste to work until the bug is marked FIXED.
Finally got my mozilla-central to build; see bug 442545.

Added an updated version of the patch that works with the latest trunk in mozilla-central.  This patch was created using Mercurial Queues and "hg export", so it looks different from the previous patches (let me know if this is bad).  It also fixes an actual bug in the last patch that prevented nsClipboard.mm from compiling.
Attachment #315217 - Attachment is obsolete: true
Sorry for the non-productive comment.

I hope this is fixed soon. Cannot paste any formatted text (+ html). Attemptred paste is always plain text with no images, formatting or html references.
Same as bug 430272?   	Rich text formatting lost with copy/paste on documents served as application/xhtml+xml.

Same as bug 437047? 	cannot paste data from other application if target is not text/plain or html

Same as bug 442545? 	OS X builderror with the 10.5SDK & GCC 4.01 (Show Votes)
	4 votes used out of 10000 allowed.

Same as bug 384496? 	Formatted text copied from a desktop application (i.e. Word, TextEdit, etc.) looses formatting when pasted into a designMode enabled element.

Flags: wanted1.9.0.x+ → wanted1.9.1+
Attachment #332415 - Flags: superreview?(roc)
Attachment #332415 - Flags: review+
+    if (flavorStr.EqualsLiteral(kUnicodeMime) ||
+        flavorStr.EqualsLiteral(kHTMLMime)) {
+      const NSString *pboardType;
+
+      if (flavorStr.EqualsLiteral(kUnicodeMime))
+        pboardType = NSStringPboardType;
+      else
+        pboardType = NSHTMLPboardType;

Instead of repeating this five times, how about a helper function
  PRBool IsStringType(const nsXPIDLCString& aMIMEType, const NSString** aPasteboardTYpe)
?
Summary: Clipboard and drag-and-drop don't interoperate with HTML on OS X → Clipboard and drag-and-drop don't interoperate with formatted text (e.g. HTML) on OS X
can someone mark bug 418606 and bug 367162 as duplicates of this one?
Atul, could you give a status update please?
Roc, does it mean sr-?
Yeah, it means the code should be cleaned up before landing.
Sorry everyone, the recent Ubiquity launch has rendered me a lot busier than usual.  I'll definitely get to this over the weekend.
I hope that this may is the correct place for this comment. I recently upgraded to Firefox 3.01. I am using a Macintosh PowerPC with OS 10.4.11. Since I upgraded to Firefox 3.01 I am unable to copy/paste text from a web site to a MS Word document. The text is garbage and symbols. Copy/paste will work if I paste the text into a TextEdit document, then convert the TextEdit document to a MS Word document. That is an extra step that was never needed before. Can I downgrade back to the previous version of Firefox? Or is there an update in the works that will fix the problem. Thanks. JB Wilson
There seem to be quite a few duplicates of this bug. 

If one totals all the duplicate bug's votes, it would imply that the priority of bug 428096 should be raised.

I do not understand how HTML,styl,rtf compatibility for the clipboard could be thought of as a non-priority for getting fixed. 

Letting it go on unfixed since 4/9/08 seems very unreasonable given all the complaints.
Whiteboard: [needs status update]
I've implemented roc's suggestion from comment #32.  Requesting that joshmoz review it b/c a fair number of lines of code have been changed... Please let me know if I shouldn't have done that though. :)
Attachment #332415 - Attachment is obsolete: true
Attachment #342357 - Flags: review?(joshmoz)
Attachment #332415 - Flags: superreview?(roc)
Whiteboard: [needs status update]
Attachment #342357 - Flags: superreview?(roc)
Attachment #342357 - Flags: review?(joshmoz)
Attachment #342357 - Flags: review+
Comment on attachment 342357 [details] [diff] [review]
Latest patch, implementing roc's suggested refactoring re: adding an IsStringType() helper function.

+    const NSString *pboardType;
+
+    if (nsClipboard::IsStringType(flavorStr, &pboardType)) {
...
+      NSString* pString = [cocoaPasteboard stringForType:pboardType];
+
       if (!pString)
...
+PRBool nsClipboard::IsStringType(const nsCString& aMIMEType, const NSString** aPasteboardType)
+{
+  if (aMIMEType.EqualsLiteral(kUnicodeMime) ||
+      aMIMEType.EqualsLiteral(kHTMLMime)) {
+
+    if (aMIMEType.EqualsLiteral(kUnicodeMime))

Please get rid of all the newlines added in these sections.
Attachment #342357 - Attachment is obsolete: true
Attachment #342523 - Flags: review?(joshmoz)
Attachment #342357 - Flags: superreview?(roc)
Attachment #342523 - Flags: review?(joshmoz) → review+
Attachment #342523 - Flags: superreview?(roc)
Comment on attachment 342523 [details] [diff] [review]
Removed extraneous newlines from joshmoz's review.

+  if (aMIMEType.EqualsLiteral(kUnicodeMime) ||
+      aMIMEType.EqualsLiteral(kHTMLMime)) {
+    if (aMIMEType.EqualsLiteral(kUnicodeMime))
+      *aPasteboardType = NSStringPboardType;
+    else
+      *aPasteboardType = NSHTMLPboardType;
+    return PR_TRUE;
+  } else
+    return PR_FALSE;

{} around return PR_FALSE.
Attachment #342523 - Flags: superreview?(roc) → superreview+
By the way, we really an automated test for this, although I'm not sure how to do it.
I agree that an automated test would be good.  One easy way to do it would be by writing an Objective-C test that puts different kinds of content on the OSX clipboard, then creates the proper XPCOM object to get the clipboard contents and makes sure they're what we expect them to be, as well as the reverse (creating an nsITransferable with different types of content and putting them into the OSX clipboard).  This obviously wouldn't test the drag-and-drop functionality, though, and I'm not really sure how to do that.
That sounds good, can you do it? Thanks :-)
Flags: in-testsuite?
Two questions:

1. I'm very interested in this bug; in the interim until automation can be developed, can I help by testing nightly builds every couple of days? I'm don't think its practical for me to apply patches and compile so I'll only be able to help once there are builds available.

Question: Is the fix likely to impact both Firefox and Thunderbird?  (I hope so as both are very important to me in relation to formatted copy/paste)

2. How do I submit a vote?  I tried the link in Comment #44 but got an error and I don't see the expected "Vote" button on this form?  Is voting just not allowed for this component?

And finally a plea...  Please please hurry and fix this and get it into some released version of both Firefox and Thunderbird.  This is a show-stopper for me since.  Even simple things like putting links in email becomes makes what should be simple workflows cumbersome.  Never mind inserting formatted html.
roc, is the existing patch ready to land? If so, can we go ahead and get this landed, and file a follow-up (or keep this bug open) for the automated testing? It seems mildly unreasonable to hold up landing a patch with sr+ simply because we don't have an automated testing framework for something the OS doesn't provide easy automation hooks for in the first place. (There's probably a way to fake it, but I'm not really sure how you can automate drag and drop testing, period.)

cl
Yes, this patch is ready to land and should do so ASAP.
Keywords: checkin-needed
As long as we can't have an automated test for we should add it at least to Litmus.
Flags: in-litmus?
Pushed 738aabad5f4b
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Attachment #342911 - Attachment description: Latest patch revision as per roc's suggestion for adding braces. → Latest patch revision as per roc's suggestion for adding braces [Checkin: Comment 58]
Keywords: checkin-needed
Target Milestone: --- → mozilla1.9.1b2
Is a build somewhere I can test?  I'd like to test for both Firefox and Thunderbird.  Can someone help me with how to go about doing this?
(In reply to comment #59)
> Is a build somewhere I can test?  I'd like to test for both Firefox and
> Thunderbird.  Can someone help me with how to go about doing this?

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/
http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-trunk/
Any trunk nightly should have the fix now:

Firefox: ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/
Thunderbird: ftp://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-trunk/

Camino nightlies haven't picked up a fix yet, as the fix has only landed in hg, not in CVS. Speaking of which, roc, can this land in CVS, too?
I have verified the fix.  It works very well.  I can copy and paste formatted text from Thunderbird and firefox to other apps like TextEdit, MS Word and NeoOffice.  Also, dragging a tab creates a link as expected.  Drag and drop of text works as expected also.

I'll keep and eye on this fix.  Apparently the nightlies autoupdate themselves regularly so it should not be too hard to check this regularly.

Thanks to all!!
The new "drag tab to new window" feature that was implemented impacted the resolution to this bug in the sense that you can no longer drag a tab to a formatted text editor and get a hyperlink using the page title as the displayed text.  

You can still drag the little icon next to the location bar but in doing that you get a hyperlink but it does not use the page title as the displayed text - it is the actual URL as the displayed text.

I assume I should just open a new bug - just looking for some input here.
Yeah, you should. I think that would be a Firefox front-end bug.
Actually, I'm not sure whether that would be a front-end UI thing or a widgets thing. The right thing might be on the pasteboard, but not get chosen for whatever reason.

It definitely should be filed, though, and be sure to mention the bug number here when you file it.
Depends on: 466599
FYI - I reported the issue mentioned above as Bug 467861
May be causing bug 468892 in some way -- see comment 2. It's no longer passing the page title to at least some applications (Adium in my case) and also messing up text formatting.
Dragging of formatted HTML link is an important use case that has been around in Firefox for a long time.  Used to be you could drag a tab or the location bar icon and it would drop into a formatted text region as an HTML link (and thus inherently with style I think).  This broke recently due I think to the new behavior added made with dragging tabs (at least the previous behavior stopped quite recently).

Its actually preferable if font styles don't go with it but I don't know if that's possible.

This but is related to Bug 467861 (Drag and drop from location bar icon into formatted text region adds incorrect display text)
Why would it not be possible when it was possible for a very long time before last month? For what it's worth I didn't try to drag tabs into other windows before (i.e. into an outgoing instant message) but when I tried it just now with 3.1b2, it not only failed to appear as a link in the outgoing IM but, for whatever insane reason, decided that "drag and drop this URL into that window" meant "I want to open a new browser window" which is NOT what I wanted at all! This doesn't make any sense since in lots of other apps, dragging something onto another application correctly infers I want to interact with that application. Twitterific, for instance, correctly creates a link to the tweet in the outgoing window. Firefox ... doesn't.
I don't know if you are commenting to what I wrote or general but FF does create a hyperlink were the displayed text is the title of the document but the underlying link is the url.  Ive used it for years to create links in email (mostly Thunderbird).  

Drag and drop can be formatted or not, just like the clipboard.  Its actually up to the receiving app what to do with the information.   I'd hate to see FF change and start sending only plain text.

Note: I'm testing on latest branch pre-release builds.
It used to be, but not anymore -- it broke. see the bug I linked to in comment 67 (the comment link there was referring to a comment in the linked bug, not the auto-linked comment in this bug; sorry for any confusion)
Jonathan, would you be willing to create some automated tests for this bug as well since you did so with bug 466599?

Probably should've had some before checkin given the regressions, but that ship has sailed...
I'd be willing to try. It's not really a similar test scenario: that test explicitly puts the HTML data type onto our pasteboard and then checks if it was properly processed en route to the system pasteboard. In this case we should trigger a drag or copy operation from a higher level, and then check which data types ended up being provided on the pasteboard as well as whether they each have the expected content.

If you'd like me to pursue this, I suggest filing a new bug assigned to me, and I'll see what I can come up with.
= See also =

bug 470642

----------------------------------------------------------------------------
           Summary|System Services             |Send rich text to Mac OS X
                  |(interapplication           |Services
                  |communication on Mac OS X): |
                  |provider services to        |
                  |support richer text in      |
                  |Mozilla applications        |
(In reply to comment #73)
> If you'd like me to pursue this, I suggest filing a new bug assigned to me, and
> I'll see what I can come up with.

Thanks Jonathan. I filed bug 471946 on this. I really appreciate you working on tests for it. :)
Is this bug actually fixed? Doesn't seem to be implemented in the firefox 3.1b2 beta.

Noticed the "Target Milestone: mozilla1.9.1b2" how do these version #s synch with the application version?

Thanks for all who are continuing to work on this issue.
This doesn't seem to be fixed in FF 3.1b2. Any status update?
Copying or dragging rich-text/HTML content from Firefox to TextEdit works for me with FF 3.1b3.
Depends on: 501688
it doesn't with latest version of windows tb either. I tried to copy email text to clipboard to paste in wordpad to make a .rtf file, but it doesn't work since wordpad says clipboard has no formatting. I would like the choice to copy to clipboard with or without formatting. instead of just stripping it out, and I should hope it gets images too.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: