Open Bug 195012 Opened 22 years ago Updated 3 years ago

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

Categories

(Thunderbird :: Message Compose Window, defect, P5)

x86
Windows 2000

Tracking

(Not tracked)

People

(Reporter: carosendahl, Unassigned)

References

()

Details

(Keywords: topembed+, Whiteboard: editorbase+ edt_x3 [GS])

Attachments

(1 file)

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
Attached file Simple Excel 2000 test case (deleted) —
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?
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.

Bulk-downgrade of unassigned, untouched DOM/Storage bug's priority.

If you have reason to believe, this is wrong, please write a comment and ni :jstutte.

Severity: normal → S4
Priority: -- → P5

Hi! This bug is still present in 91.7.0, could you fix it please?

The severity field for this bug is relatively low, S4. However, the bug has 15 votes.
:hsinyi, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(htsai)

(In reply to Release mgmt bot [:marco/ :calixte] from comment #21)

The severity field for this bug is relatively low, S4. However, the bug has 15 votes.
:hsinyi, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

yes please

It's about Thunderbird message composition. I'm moving the component and forwarding the needinfo to Magnus for further thoughts.
Please feel free to reset the component back if I miss anything. Thanks.

Component: DOM: Editor → Message Compose Window
Flags: needinfo?(htsai) → needinfo?(mkmelin+mozilla)
Product: Core → Thunderbird
Target Milestone: Future → ---
Flags: needinfo?(mkmelin+mozilla)

The situation with table formatting in TB has worsened in the last versions of TB. Currently using the latest version (91.9.0).

Until recently we could at least copy an unformatted (Normal style) table from Excel and format it in TB. TB would send the table as appeared in the editor.

Now we can still do that, but the table is no more sent as it appears in the editor. In fact it is sent as a totally unformatted table, without gridlines (borders), without colors, etc.

In its current state, TB editor simply does not appear to observe any table formatting at all when sending mail.

In a newly composed message stored as a draft, the (formatted in TB editor) table is not viewable as a formatted one; however if one edits the draft, the table is shown as initially formatted!

The same with sent messages: when viewed in the Sent Mails, the mail appears as unformatted; however, if one opens the message using the option: "Edit as new message", then the table appears as it was originally formatted (as it should be displayed in the first place)!

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: