Closed Bug 572642 Opened 14 years ago Closed 14 years ago

Paste text from OpenOffice writer to Google Docs not working

Categories

(Core :: DOM: Editor, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla2.0b1
Tracking Status
blocking2.0 --- beta1+
blocking1.9.2 --- .9+
status1.9.2 --- .9-fixed
blocking1.9.1 --- .12+
status1.9.1 --- .12-fixed

People

(Reporter: andrea.ippo, Assigned: ehsan.akhgari)

References

Details

(Keywords: regression, Whiteboard: required on branches by bug 520189 [qa-examined-192] [qa-examined-191])

Attachments

(2 files, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; it-IT; rv:1.9.3a6pre) Gecko/20100616 Minefield/3.7a6pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; it-IT; rv:1.9.3a6pre) Gecko/20100616 Minefield/3.7a6pre

When I try to paste some text copied from a writer document into a Google Doc using the Ctrl-V shortcut, only two '*' appear.
When I use the same paste command accessing it from the Edit menu of the browser, I get a google message saying the browser does not permit access to the clipboard contents.

Instead, pasting a text selection copied from a simple text editor (tried notepad, Textpad) works.

So a workaround for now is to paste the text into a simple text editor and only after that paste it into google docs.
Is this perhaps related to text formatting somehow? Seems a regression, since Firefox 3.6.3 isn't affected.

Also tried with a clean profile of course.

Reproducible: Always

Steps to Reproduce:
1. Open a text google doc
2. copy some text from a document opened with OpenOffice Writer (perhaps the same happens with MS Office Word, dunno)
3. paste it in the google doc using Ctrl+V or the browser Paste command in the Edit menu
Actual Results:  
The text is not pasted, either "**" appears, or a message window opens, informing that the browser does not permit access to the clipboard contents.

Expected Results:  
The text is pasted
fyi, the opposite way has been fixed in Bug 537414 recently.
Component: General → Widget: Win32
Product: Firefox → Core
QA Contact: general → win32
Version: unspecified → Trunk
This problem however involves only Google Docs. Pasting Writer contents to forms, forum comments, even Microsoft Word Web App, works.
I can reproduce with Microsoft Office Word2003 SP3 and Mozilla/5.0 (Windows; U; Windows NT 6.1; WOW64; en-US; rv:1.9.3a6pre) Gecko/20100618 Minefield/3.7a6pre ID:20100618040705

It does not happen on Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.6pre) Gecko/20100617 Namoroka/3.6.6pre ID:20100617041816


Regression window:

Works:
http://hg.mozilla.org/mozilla-central/rev/dcfe95c71a04
Mozilla/5.0 (Windows; U; Windows NT 6.1; WOW64; en-US; rv:1.9.3a6pre) Gecko/20100614 Minefield/3.7a6pre ID:20100614135921

Fails:
http://hg.mozilla.org/mozilla-central/rev/3c23833e5c1b
Mozilla/5.0 (Windows; U; Windows NT 6.1; WOW64; en-US; rv:1.9.3a6pre) Gecko/20100614 Minefield/3.7a6pre ID:20100614145614

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=dcfe95c71a04&tochange=3c23833e5c1b

Candidate:
Mon Jun 14 13:52:39 2010 -0700	208d7f999037	Ehsan Akhgari Bug 520189 - Fix copy and test for the HTML editor
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
This is similar to Bug 572637 - Paste image into Compose window broken with Shredder
Anyone able to test against Linux/MacOS (using OpenOffice)?
blocking2.0: --- → ?
On Mac, a much worse issue exists, which is actually an OpenOffice bug.  I've filed that as <http://www.openoffice.org/issues/show_bug.cgi?id=112525>.
I'm currently building on Windows to see what's going on.  This could be a Windows-only issue, because how HTML is handled in the clipboard is totally different in Windows and other OSes.
Component: Widget: Win32 → Editor
QA Contact: win32 → editor
Assignee: nobody → ehsan
(In reply to comment #4)
> This is similar to Bug 572637 - Paste image into Compose window broken with
> Shredder

Not really!  :-)
This problem happens on rich text editor of  http://www.mozilla.org/editor/midasdemo/  too.

(In reply to comment #5)
> Anyone able to test against Linux/MacOS (using OpenOffice)?

I can *Not* reproduced on Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a6pre) Gecko/20100618 Minefield/3.7a6pre + Openoffice 2.4.1


(In reply to comment #8)
> (In reply to comment #4)
> > This is similar to Bug 572637 - Paste image into Compose window broken with
> > Shredder
> 
> Not really!  :-)

Oh my bad.
Component: Editor → Widget: Win32
(In reply to comment #9)
> This problem happens on rich text editor of 
> http://www.mozilla.org/editor/midasdemo/  too.

Yes.  It happens on any contenteditable element.

> (In reply to comment #5)
> > Anyone able to test against Linux/MacOS (using OpenOffice)?
> 
> I can *Not* reproduced on Mozilla/5.0 (X11; U; Linux i686; en-US;
> rv:1.9.3a6pre) Gecko/20100618 Minefield/3.7a6pre + Openoffice 2.4.1

This confirms my suspicion that this has something to do with the CF_HTML clipboard type.  Thanks for testing this!
Assignee: ehsan → nobody
Component: Widget: Win32 → Editor
Attached patch Patch (v1) (obsolete) — — Splinter Review
We don't need to allow styles while parsing the context.  This fixes pasting from OpenOffice, and we don't want that anyway, I guess.
Assignee: nobody → ehsan
Status: NEW → ASSIGNED
Attachment #452868 - Flags: review?(roc)
Actually, there was more here than caught my eye.

What happens is that we use a comment when parsing the context for CF_HTML format from the clipboard.  But the paranoid content sink does not allow comments.  So we need to allow comments when parsing styles.  This patch does that.

I'm trying to come up with a test case for this as well.
Attachment #452868 - Attachment is obsolete: true
Attachment #452893 - Flags: review?(roc)
Attachment #452868 - Flags: review?(roc)
Attached patch Part2: tests — — Splinter Review
Here is a set of tests for our CF_HTML handling.  The cfhtml-*.txt files come from the Clipboard Spy tool recording the actual clipboard contents on Windows from Firefox, Chromium, OpenOffice.org and IE.
Attachment #452957 - Flags: review?(roc)
Comment on attachment 452957 [details] [diff] [review]
Part2: tests

lovely
Attachment #452957 - Flags: review?(roc) → review+
(In reply to comment #14)
> (From update of attachment 452957 [details] [diff] [review])
> lovely

So, I noticed a problem with the tests on the try server.  The tests failed in nsITransferable::GetTransferData on Windows and Linux, and passed on Mac.  After debugging, I can confirm that when trying to copy the data to the clipboard, the platform APIs pretend that the data is available on the clipboard, but it really isn't.  This might explain why these tests pass on Mac, because Mac has no notion of "native html" for clipboard at all.

Given the fact that our CF_HTML code is cross-platform, and that I really don't have any idea how I can put the correct data on clipboard on Windows and Linux, I was planning to make this test Mac-only and land it.  Roc, do you agree?
(In reply to comment #15)
> So, I noticed a problem with the tests on the try server.  The tests failed in
> nsITransferable::GetTransferData on Windows and Linux, and passed on Mac. 
> After debugging, I can confirm that when trying to copy the data to the
> clipboard, the platform APIs pretend that the data is available on the
> clipboard, but it really isn't.  This might explain why these tests pass on
> Mac, because Mac has no notion of "native html" for clipboard at all.

I don't understand.
(In reply to comment #16)
> (In reply to comment #15)
> > So, I noticed a problem with the tests on the try server.  The tests failed in
> > nsITransferable::GetTransferData on Windows and Linux, and passed on Mac. 
> > After debugging, I can confirm that when trying to copy the data to the
> > clipboard, the platform APIs pretend that the data is available on the
> > clipboard, but it really isn't.  This might explain why these tests pass on
> > Mac, because Mac has no notion of "native html" for clipboard at all.
> 
> I don't understand.

When I call nsIClipboard::SetData, the call returns successfully.  When I call nsIClipboard::GetData later on, that call also returns successfully.  But when I call nsITransferable::GetTransferData on the transferable passed to nsIClipboard::GetData, it throws.  Things work correctly for any mime type except application/x-moz-nativehtml, which is why I suspect that Windows and Linux do something special with CF_HTML data under the hoods...
Hmm, is it possible to track down the cause of the throw?
(In reply to comment #18)
> Hmm, is it possible to track down the cause of the throw?

The cause is that the platform clipboard APIs do not give us any data.  :-)

I'm not sure how we should fix that.  I guess this has something to do with the way that we should put native html data on the clipboard, but I wasn't able to figure out how to do that correctly so that we can actually get the data back from the clipboard.

Come to think of it, one other way to handle things would be for me to override the clipboard xpcom component in the test and make it return the data that I want, but I don't think that's going to catch all the ways we can fail in the future with a real clipboard.
Is it just a delay issue, or does the data never arrive?

If it's just a delay, we could poll in the test.
(In reply to comment #20)
> Is it just a delay issue, or does the data never arrive?
> 
> If it's just a delay, we could poll in the test.

I already poll in the test, but no, the data never arrives!
So does copy and paste of HTML from one Firefox instance to another work at all?
(In reply to comment #22)
> So does copy and paste of HTML from one Firefox instance to another work at
> all?

Yes, but we don't use the CF_HTML format when copying from Firefox.  We just put the HTML itself plus the context and info information as separate flavors on the clipboard <http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsCopySupport.cpp#204>.
In other words, we don't currently have any call site in our tree which attempts to put CF_HTML content on the clipboard.  We only support pasting it from the clipboard.
Ok then, go ahead and make the test Mac-only :-(
(In reply to comment #25)
> Ok then, go ahead and make the test Mac-only :-(

OK.  I filed bug 574005 so that I have something to stay on my conscious in the future, in case I can think of a way to fix this in the future.
http://hg.mozilla.org/mozilla-central/rev/4e74c58e6020
http://hg.mozilla.org/mozilla-central/rev/b149725f51da
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a6
Comment on attachment 452893 [details] [diff] [review]
Part 1: Allow comments and disallow styles when parsing the context for CF_HTML content on the clipboard

We have to take this patch on branches as well if we want to take the patch to bug 520189, since this is a pretty important regression from that patch.
Attachment #452893 - Flags: approval1.9.2.7?
Attachment #452893 - Flags: approval1.9.1.12?
Comment on attachment 452893 [details] [diff] [review]
Part 1: Allow comments and disallow styles when parsing the context for CF_HTML content on the clipboard

> #define NS_I_PARANOID_FRAGMENT_CONTENT_SINK_IID \
>-  { 0x59ec77f5, 0x9e9b, 0x4040, \
>+  { 0x69ec77f5, 0x9e9b, 0x4040, \
>     { 0xbd, 0xe7, 0x4e, 0xd0, 0x13, 0xa6, 0x21, 0x74 } }

Please don't just change one bit in order to rev an IID. If you're going to rev it, actually rev it. This should be fixed, imho. What stops somebody in the future from doing the same thing but changing the 6 back to a 5? Better to just change it completely.
Yes, the risk of collisions goes up dramatically when you don't generate a new UUID using standard tools. Please use guidgen/uuidgen to generate new UUIDs.
You're completely right, sorry about that mistake.  Fixed in <http://hg.mozilla.org/mozilla-central/rev/c8df4a1c8860>
Comment on attachment 452893 [details] [diff] [review]
Part 1: Allow comments and disallow styles when parsing the context for CF_HTML content on the clipboard

> #define NS_I_PARANOID_FRAGMENT_CONTENT_SINK_IID \
>-  { 0x59ec77f5, 0x9e9b, 0x4040, \
>+  { 0x69ec77f5, 0x9e9b, 0x4040, \
>     { 0xbd, 0xe7, 0x4e, 0xd0, 0x13, 0xa6, 0x21, 0x74 } }

Is this an interface we can change on the branch?
(In reply to comment #32)
> Comment on attachment 452893 [details] [diff] [review]
> Part 1: Allow comments and disallow styles when parsing the context for CF_HTML
> content on the clipboard
> 
> > #define NS_I_PARANOID_FRAGMENT_CONTENT_SINK_IID \
> >-  { 0x59ec77f5, 0x9e9b, 0x4040, \
> >+  { 0x69ec77f5, 0x9e9b, 0x4040, \
> >     { 0xbd, 0xe7, 0x4e, 0xd0, 0x13, 0xa6, 0x21, 0x74 } }
> 
> Is this an interface we can change on the branch?

Yes.  It was introduced in bug 520189, which means that it's a new interface when/if that bug lands on branch.
Comment on attachment 452893 [details] [diff] [review]
Part 1: Allow comments and disallow styles when parsing the context for CF_HTML content on the clipboard

I'm not sure we can approve this patch for the stable branches because you're changing interfaces. This one's not an .idl so maybe it's OK?
blocking1.9.1: --- → .12+
blocking1.9.2: --- → .9+
Whiteboard: required on branches by bug 520189
(In reply to comment #34)
> I'm not sure we can approve this patch for the stable branches because you're
> changing interfaces. This one's not an .idl so maybe it's OK?

It's OK, not because it's not an IDL interface, but because this is a new interface introduced in bug 520189.
dveditz: see comment 35 please.
Comment on attachment 452893 [details] [diff] [review]
Part 1: Allow comments and disallow styles when parsing the context for CF_HTML content on the clipboard

Approved for 1.9.2.9 and 1.9.1.12, a=dveditz
Attachment #452893 - Flags: approval1.9.2.9?
Attachment #452893 - Flags: approval1.9.2.9+
Attachment #452893 - Flags: approval1.9.1.12?
Attachment #452893 - Flags: approval1.9.1.12+
Backed out because bug 520189 was backed out (see bug 520189 comment 83).
I forgot to update the status flags for branches.
I cannot reproduce the original problem.

Using Openoffice 3.2.1, I've created a new document. I've done both simple text in it and text with font face, style, and size settings added.

I select the text and use ctrl-c to copy it.

I open Firefox 3.6.8, go to Google Docs, and create a new document. In that document, I use ctrl-v or the browser paste option under the edit menu. In both instances, the text appears without issues.

This was on Windows XP. 

In no case, is the pasted text replaced with **.

The a message window opening and stating that the browser does not permit access to the clipboard contents only happens if the Google Docs paste menu is used. This is a Google docs issue (and occurs in the current nightly 1.9.2.9pre build as well). 

I see no difference in behavior between 3.6.8 and the nightly 1.9.2 build and I cannot reproduce the bug.
Have you tried to see if you can reproduce the problem on a trunk version before this bug fixed?
(In reply to comment #43)
> Have you tried to see if you can reproduce the problem on a trunk version
> before this bug fixed?

Yes, if I use a trunk build before the fix, the clipboard contents fail to paste. After the fix, they work.

In 1.9.2, the paste works without any problems both pre and post-fix.
Whiteboard: required on branches by bug 520189 → required on branches by bug 520189 [qa-examined-192] [qa-examined-191]
(In reply to comment #44)
> (In reply to comment #43)
> > Have you tried to see if you can reproduce the problem on a trunk version
> > before this bug fixed?
> 
> Yes, if I use a trunk build before the fix, the clipboard contents fail to
> paste. After the fix, they work.
> 
> In 1.9.2, the paste works without any problems both pre and post-fix.

Hmm, this shouldn't really be happening.  I don't know why it does.  But at any rate, we do want this fix on 1.9.2...
Depends on: 591544
Depends on: 591750
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: