Closed Bug 228879 Opened 20 years ago Closed 20 years ago
Bogus Text when pasting from open office spread sheet or word processor to Mail Compose
1) In an Open Office Spreadsheet, type some text in a cell like "Scott". 2) Copy the cell to the clipboard 3) Now paste the clipboard contents into an html mail compose window We show the following: TEXT="#000000"> Scott (under the covers, Scott is wrapped with a table/table cell tags as part of the paste contents) 4.x can handle this cfHTML data just fine. Very strange.
Here is the source code open office uses to generate their HTML fragment for the windows clipboard: http://ooo.ximian.com/lxr/source/cvsup/gsl/dtrans/source/win32/dtobj/FmtFilter.cxx#303 In our code, nsHTMLEditor::ParseCFHTML is the method that figures out the correct string fragment to paste from the clipboard format. open office says the string fragment starts RIGHT after the open BODY tag but before the open body tag closes. I guess it wants us to see the styles in the body tag which look like: <BODY TEXT="#000000"> So reading through startFragment bytes from the start of the clipboard data leaves the start of the fragment as: TEXT="#000000"> instead of the <table> tag which immediately follows. And that's why we get the extra text showing up in our paste. I'm not sure how 4.x is able or knows to skip over this.....Maybe Joe does.
I think the problem is in the O.O. code. the code that generates clipboard data has a problem. from the O.O. code: http://ooo.ximian.com/lxr/source/gsl/dtrans/source/win32/dtobj/FmtFilter.cxx#288 // we don't include '>' into the search // because the body tag allows parameters // e.g. <BODY param> // #92840# OString startBodyTag( "<BODY" ); ... nStartFrgmt = nStartFrgmt + startBodyTag.getLength( ) + lHTMLFmtHdr; // after the <BODY> tag this only works if we really have <BODY>. if you have <BODY TEXT="#000000">, it will set the start fragment byte count to the wrong place, as we are seeing. I'll start an open office bug. weird thing is that this works when you paste into OE and Word, but they might have better CF_HTML handling code, or not care about the fragment offsets? (just a guess) I'll start the open office bug.
> I'll start the open office bug. http://www.openoffice.org/issues/show_bug.cgi?id=25864
I can also reproduce this by using the O.O. word processor. 1) create a new text document 2) type the word "test" 3) select the word "test" 4) change the font color to blue 5) select all, copy 6) paste into mozilla. you'll end up with: DIR="LTR"> test in mozilla, because of the same bug. the clipboard has: <BODY DIR="LTR"> and O.O. is calculating an incorrect byte count for StartFragment.
Summary: Bogus Text when pasting from open office spread sheet to Mail Compose → Bogus Text when pasting from open office spread sheet or word processor to Mail Compose
20 years ago
Comment on attachment 142320 [details] [diff] [review] patch thanks a lot seth!
Attachment #142320 - Flags: superreview?(mscott) → superreview+
Comment on attachment 142320 [details] [diff] [review] patch pinging joe instead, per daniel.
Attachment #142320 - Flags: review?(daniel) → review?(jfrancis)
First, off, I'd just like to say that OO code is an attrocity. Making cfHTML starts or ends point inside the middle of a tag is way more heinous than even any of MY hacks!
Comment on attachment 142320 [details] [diff] [review] patch looks good to me. r=jfrancis
Attachment #142320 - Flags: review?(jfrancis) → review+
fixed on the trunk (1.7 beta) Checking in nsHTMLDataTransfer.cpp; /cvsroot/mozilla/editor/libeditor/html/nsHTMLDataTransfer.cpp,v <-- nsHTMLData Transfer.cpp new revision: 1.99; previous revision: 1.98 done
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.7beta
oops, a mistake in my patch. with good clipboard data, we will start on '<', and in that case, we want to leave the clipboard alone. supplimental patch coming...
supplimental fix landed. Checking in libeditor/html/nsHTMLDataTransfer.cpp; /cvsroot/mozilla/editor/libeditor/html/nsHTMLDataTransfer.cpp,v <-- nsHTMLData Transfer.cpp new revision: 1.100; previous revision: 1.99 done
You need to log in before you can comment on or make changes to this bug.