Bug 47615 – REGRESSION: Copied content loses formatting on paste to external apps

• Component: HTML Editing
• Status: RESOLVED FIXED

[Jochen Sprenger]

If you highlight a passage on a webpage and copy it to a texteditor, the copied passage loses all formatting.
This allies to all the text as well as images (latter ones are completely ignored during paste).
This not only happens if you copy the highlighted part to your clipboard and paste it into a new document outside of webkit/Safari.
It happens as well if you highlight a portion of a webpage, click and hold the highlighted part and then drag it to an new document (in TextEdit for example).

[Alexey Proskuryakov]

Could you please provide step by step instructions to reproduce this?

Here is what I tried, and didn't see any problems:
1. Open http://www.apple.com/safari/ in Safari 5.0.2.
2. Selected a paragraph starting with "It has innovative new features".
3. Pressed Cmd+C to copy it.
4. Launched TextEdit, which opened a blank document.
5. Pressed Cmd+V to paste.

All formatting was preserved.

[Jochen Sprenger]

Maybe I was unclear in my initial posting. You are right, that formatting is preserved in Safari.
But if you launch WebKit, the formatting is gone.
So just go to http://nightly.webkit.org/ and download the latest nightly build (I just tested the current build r69728).
Install and launch it.
Then follow your very own steps and you’ll see that he formatting won’t transfer.

Please post back if you have additional questions.
And sorry for the typos in post #1.

(In reply to comment #1)
> Could you please provide step by step instructions to reproduce this?
> 
> Here is what I tried, and didn't see any problems:
> 1. Open http://www.apple.com/safari/ in Safari 5.0.2.
> 2. Selected a paragraph starting with "It has innovative new features".
> 3. Pressed Cmd+C to copy it.
> 4. Launched TextEdit, which opened a blank document.
> 5. Pressed Cmd+V to paste.
> 
> All formatting was preserved.

[Alexey Proskuryakov]

Thank you, I can reproduce this with a nightly build. Should have tried right away, but this didn't sound like a typical WebKit bug, so I asked for clarification instead.

[Alexey Proskuryakov]

<rdar://problem/8553404>

[Ryosuke Niwa]

(In reply to comment #1)
> Here is what I tried, and didn't see any problems:
> 1. Open http://www.apple.com/safari/ in Safari 5.0.2.
> 2. Selected a paragraph starting with "It has innovative new features".
> 3. Pressed Cmd+C to copy it.
> 4. Launched TextEdit, which opened a blank document.
> 5. Pressed Cmd+V to paste.

This seems to be some bug with clipboard.  We DO preserve the style when I paste it on http://www.mozilla.org/editor/midasdemo/

Alexey & Enrica:
do we use WebKit2 for nightly yet?

[Alexey Proskuryakov]

> do we use WebKit2 for nightly yet?

No. There is no way to use it with nightlies in Safari 5.0.2.

[Jochen Sprenger]

> This seems to be some bug with clipboard.  We DO preserve the style when I paste it on http://www.mozilla.org/editor/midasdemo/
>

I don’t know what you mean with mozilla, but using WebKit you also loose formatting when you drag text out of the browser and into a textdocument.
As far as I know during drag&drop the clipboard is not involved.
(At least the dragged part ain’t in your clipboard after dropping).

[Hajime Morrita]

I've just play with this a bit.
I wonder why other apps can read NSHTMLPboardTypes from the pboard regardless
WebKit doesn't write with that type.
It looks WebKit just provides
WebArchivePboardType, NSRTFDPboardType, NSRTFPboardType, NSStringPboardType....

[Tony Chang]

(In reply to comment #8)
> I've just play with this a bit.
> I wonder why other apps can read NSHTMLPboardTypes from the pboard regardless
> WebKit doesn't write with that type.
> It looks WebKit just provides
> WebArchivePboardType, NSRTFDPboardType, NSRTFPboardType, NSStringPboardType....

WebKit doesn't write text/html to the pasteboard because it broke MS Office 2004.
http://trac.webkit.org/changeset/6793
https://bugs.webkit.org/show_bug.cgi?id=19893

However, WebArchivePboardType should include the information necessary to paste HTML.

[Alexey Proskuryakov]

*** Bug 48115 has been marked as a duplicate of this bug. ***

[Alexey Proskuryakov]

*** Bug 54500 has been marked as a duplicate of this bug. ***

[Alexey Proskuryakov]

> <rdar://problem/8553404>

Now tracked as <rdar://problem/9001214>

[Enrica Casucci]

Created attachment 83549 [details]
Patch

[Darin Adler]

Comment on attachment 83549 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=83549&action=review

OK to land this as-is, but over time we should make this use coding style closer to the rest of WebKit.

> Source/WebCore/platform/mac/PasteboardMac.mm:153
> +        // In WebKit2 we are using a different way to create the NSAttributedString from the DOMrange that doesn't require access to the WebView.

Typo: "DOM range" instead of "DOMrange".

[Enrica Casucci]

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

[James Robinson]

This doesn't seem to compile on my Snow Leopard box or the Leopard builder on build.webkit.org (the SL builder hasn't cycled yet):


/usr/local/home/jamesr/WebKit/Source/WebCore/platform/mac/HTMLConverter.mm:41:41: error: Foundation/NSURL_NSURLExtras.h: No such file or directory
cc1objplus: warnings being treated as errors
/usr/local/home/jamesr/WebKit/Source/WebCore/platform/mac/HTMLConverter.mm: In function ‘NSFileWrapper* fileWrapperForURL(WebCore::DocumentLoader*, NSURL*)’:
/usr/local/home/jamesr/WebKit/Source/WebCore/platform/mac/HTMLConverter.mm:785: warning: ‘NSURL’ may not respond to ‘-_web_suggestedFilenameWithMIMEType:’
/usr/local/home/jamesr/WebKit/Source/WebCore/platform/mac/HTMLConverter.mm:785: warning: (Messages without a matching method signature
/usr/local/home/jamesr/WebKit/Source/WebCore/platform/mac/HTMLConverter.mm:785: warning: will be assumed to return ‘id’ and accept
/usr/local/home/jamesr/WebKit/Source/WebCore/platform/mac/HTMLConverter.mm:785: warning: ‘...’ as arguments.)


is someone working on fixing it or should I roll this out for now?

[Geoffrey Garen]

I rolled this out in http://trac.webkit.org/changeset/79513. Reopening.

[Geoffrey Garen]

There were two build failures.

Leopard (32bit-64bit conversions):

http://build.webkit.org/builders/Leopard%20Intel%20Release%20%28Build%29/builds/30390/steps/compile-webkit/logs/stdio

SnowLeopard (Private header issues):

http://build.webkit.org/builders/SnowLeopard%20Intel%20Leaks/builds/15096/steps/compile-webkit/logs/stdio

[Enrica Casucci]

Landed with build fix. http://trac.webkit.org/changeset/80497

[WebKit Review Bot]

http://trac.webkit.org/changeset/80497 might have broken Chromium Mac Release

[Enrica Casucci]

Reopening because of the failures on the 32-bit builds.

[Enrica Casucci]

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