Closed Bug 228879 Opened 21 years ago Closed 20 years ago

Bogus Text when pasting from open office spread sheet or word processor to Mail Compose

Categories

(Core :: DOM: Editor, defect)

Product:
Core
Component:
DOM: Editor
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.7beta

People

(Reporter: mscott, Assigned: mozeditor)

Details

Attachments

(2 files)

patch
1.53 KB, patch
mozeditor
: review+
mscott
: superreview+
Details | Diff | Splinter Review
supplimental patch
986 bytes, patch
Details | Diff | Splinter Review 
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 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
Attachment #142320 - Flags: superreview?(mscott)
Attachment #142320 - Flags: review?(daniel)
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.

Attachment

General

Creator:
Created:
Updated:
Size: