Retain fonts/styles when pasting tables from Excel into composition window

NEW
Unassigned

Status

()

defect
17 years ago
3 years ago

People

(Reporter: carosendahl, Unassigned)

Tracking

({topembed+})

Trunk
Future
x86
Windows 2000
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: editorbase+ edt_x3 [GS], )

Attachments

(1 attachment)

1.  Open the attached test case in excel.
2.  Copy the cells with all of the formatting and text.
3.  Paste into the compose window

Expected result:
Fonts/formatting preserved

Actual result:
formatting/fonts lost.
Whiteboard: edt_x3
Keywords: nsbeta1, topembed
Whiteboard: edt_x3 → editorbase edt_x3
I ran across two interesting issues when testing this.
1. if I created a table in excel putting text in A1:D5 and then select from
A1:D5, select copy and paste into composer -- I do not get the first row.
2. if I copy/paste from excel, the format is lost, as indicated here. However,
if I first paste the table into Word and then copy from there, the format is
preserved.
QA Contact: sujay → beppe
Blocks: PhtN5
Discussed in edt.  topembed plussing.  Also editorbase plussing based on saari's
directive.
Keywords: topembedtopembed+
Whiteboard: editorbase edt_x3 → editorbase+ edt_x3
Keywords: nsbeta1nsbeta1+
Nisheeth can you take a look?
Assignee: jfrancis → nisheeth
Target Milestone: --- → mozilla1.4final
Will look at this for 1.5 alpha...
Target Milestone: mozilla1.4final → mozilla1.5alpha
adt: nsbeta1-
Keywords: nsbeta1+nsbeta1-
Hmm, this is an interesting bug.  I'm attaching test.doc (the Word XP test case)
and paste-output.html, the html that gets put on the clipboard when you copy
test.doc's contents.

The problem is that none of the style rules in the head get applied to the 
tags in the body. This is because we ignore the context part of the CF_HTML
format (the head and the style definitions) on the clipboard, we only process
the HTML fragment part (the contents of the body). Consequently, the table loses
fonts/styles.

We can't simply start processing the head section because style rules might
conflict with those already in the document from earlier. Joe suggested that I
talk with Daniel Glazman to see if we can come up with a workaround. Ccing him
on this bug...
After talking with Daniel Glazman about this, we've decided to punt on this for
now.  The fix will entail the following: 

1) create a temporary document
2) run the frame constructor on the DOM fragment for the pasted HTML to create
the frame model
3) compute resolved style on that frame model based on the style rules specified
in the context part of the pasted HTML (see pasted-html.txt which I am just
about to attach to see the "context" and the "fragment" parts of the HTML placed
on the cliboard by MS Office apps)
4) apply the resolved style to the DOM fragment by adding style attributes to
all content elements that need them
5) attach the "style annotated" DOM fragment into the main document targeted by
the paste operation.
6) throw away the temp document and continue with the paste operation as earlier

All of this will need to happen during the paste operation and will slow it down
significantly.  We should probably sniff the context for markup that identifies
the pasted HTML as a MS Office paste before we do all of the above processing.

Putting this back on Joe's plate and futuring it...
Assignee: nisheeth → jfrancis
Target Milestone: mozilla1.5alpha → Future
*** Bug 272920 has been marked as a duplicate of this bug. ***
QA Contact: rubydoo123 → editor
Assignee: mozeditor → nobody
This bug still exist in Thunderbird 2.0
The only workaround I found is to copy Excel content to MS Word and then copy it from there and paste into TB composition window to retain the formatting.
Anyone working on this bug?
Duplicate of this bug: 409193
Hi, Nisheeth and Daniel. This bug is already 7-8 years old and has not been fixed even in the latest TB 3.0
I am glad to see that Daniel is working on another very old bug: https://bugzilla.mozilla.org/show_bug.cgi?id=250539 and I was wondering if maybe this bug is also related to it and can be addressed too at the same time.
Please remember that all other competing mail clients allow copying from excel straight to the composition window without any problem, this is a bug that only exists in TB.
Whiteboard: editorbase+ edt_x3 → editorbase+ edt_x3 [GS]
Just upgraded from TBird 10 to TBird 17. This problem seems to have re-appeared. 
In TB 10, I could copy/paste from OpenOffice Calc into a new message. Fonts were sometimes larger than expected, but otherwise formatting was mostly ok. In TB 17:
1. Fonts in the table/grid are teensy
2. Fonts in the rest of the message also become teensy (eg, I start to type some text into the message window, like "See the list below". Then I paste from OO-Calc. The pasted table is teensy, and the already-entered text also changes to a teensy font)
3. If I adjust the fonts so that it looks OK in my message window, the recipient of the email reports that the fonts on both are very large. 
4. Maybe Related - Messages received from Outlook users (not sure about versions) tend to appear much smaller in my read-message window than they were in the sender's Outlook window. 

Somewhere between V3.1.x and v10 this seems to have been fixed. Somewhere between v10 and v17, it has regressed its way back. 

thanks,
rich
What is the problem here? Does Mozilla does not have the resource to fix an issue that thousands of users are facing and have been complaining from 2003?

I think they should devote some resources to fix this very important issue to with cut and paste from Excel. It is very annoying and the more it is delayed, it feels that though Mozilla knows the issue, they do not care if it is fixed.

I am a fan of Mozilla and I care for its reputation, I have an easy way out of this to move to MS Outlook, but no, I want Mozilla to fix this issue and I still want thunderbird. Even with the copying to MS word and then to Thunderbird sometimes has formatting issues, I will see how long can Mozilla drag this.....I am very patient..
similar problem arises with OpenOffice 4.0.1 + Thunderbird 24.5.0
and when copying table from LibreOffice 4.2.0.4 in New Message window (Thunderbird 24.5.0) - data is not inserted
This problem still exists after +10 years! This affects the usage for newcomers! Perhaps it should be marked has an accessibility hassle. It need to be solved asap. Please.
Same here. I have thunderbird 31.2.0 upgraded and found this problem is still happening. This behavior makes me to hesitate to use thunderbird when I needed to compose email and had to include some excel tables with its orginal format and styles to be retained.
I have both excel 97 (legacy apps) and excel 2010 on win7x64 (yes I know 97 is not supported on 7 but it works near perfectly) and tried also 97 on XP.

so I can try several formatted cells copy/paste:
* from 97 to thunderbird: pasted as image (xp or 7 same result)
* from 2010 to thunderbird: pasted as table, but no formatting AND screws table cells if there is some excel 2010 cell word wrap, and adjacent cells are shifetd (yes it screws columns once pasted...)
* libreoffice 4.4.1.2: pasted as table, with formatting

latest thunderbird version tried: 31.5

so, I guess this is more an office 2010 bug than a thunderbird one, to me.

That said, an option to choose how to paste would be nice (eg: image or table), in TB.
You need to log in before you can comment on or make changes to this bug.