758999 - Font size changes when pasting cells from LibreOffice Calc

Status: REOPENED

(Core :: DOM: Editor, defect)

Description

[ian wood]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:12.0) Gecko/20100101 Firefox/12.0
Build ID: 20120423122843

Steps to reproduce:

1. click 'Write' (Create a new message)
2. type some text
3. select and copy a cells from LibreOffice Calc with default formatting
4. paste into the new message


Actual results:

The font size of all text in the new message (including pasted table contents) is very small.


Expected results:

The font size should not be affected by pasting text into the message

Comment 1

[ian wood]

It's a standard build from an Ubuntu 12.04 package repository.

I observed this behaviour when using a new profile and in safe-mode. I ran thunderbird with this command:
   thunderbird  -ProfileManager -safe-mode -compose

contents of "Troubleshooting Information" :



  Application Basics

    Name: Thunderbird
    Version: 12.0.1
    User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
    Profile Directory: Open Directory

              (Local drive)
    Application Build ID: 20120430052736
    Enabled Plugins: about:plugins
    Build Configuration: about:buildconfig
    Crash Reports: about:crashes
    Memory Use: about:memory

  Mail and News Accounts
    account1:
      INCOMING: account1, , (imap) anumail.anu.edu.au:143, alwaysSTARTTLS, passwordCleartext
      OUTGOING: mail.anu.edu.au:587, alwaysSTARTTLS, passwordCleartext, true

    account2:
      INCOMING: account2, , (none) Local Folders, plain, passwordCleartext

  Extensions
    EDS Contact Integration, 0.3.9, true, [e-mail]
    Global Menu Bar integration, 2.0.6, true, [e-mail]
    Lightning, 1.4, true, {e2fda1a4-762b-4020-b5ad-a41df1933103}
    Messaging Menu and Unity Launcher integration, 0.8.3, true, [e-mail]
    Provider for Google Calendar, 0.13, true, {a62ef8ec-5fdc-40c2-873c-223b8a6925cc}
    Timezone Definitions for Mozilla Calendar, 1.2011n, true, [e-mail]

  Important Modified Preferences

    Name: Value

      browser.cache.disk.capacity: 1048576
      browser.cache.disk.smart_size_cached_value: 276480
      browser.cache.disk.smart_size.first_run: false
      extensions.lastAppVersion: 12.0.1
      mail.openMessageBehavior.version: 1
      network.cookie.prefsMigrated: true

  Graphics

    Adapter Description: X.Org -- Gallium 0.4 on AMD RV620
    Vendor ID: .Org
    Device ID: V620
    Driver Version: 2.1 Mesa 7.11
    WebGL Renderer: X.Org -- Gallium 0.4 on AMD RV620 -- 2.1 Mesa 7.11
    GPU Accelerated Windows: 0/2

Comment 2

[ian wood]

Looking at the HTML source (via select-all then Insert->HTML...) I found this appended after the HTML table containing the pasted cells:

<title></title>
<meta name="GENERATOR" content="LibreOffice 3.4 (Unix)">
<style>
		<!-- 
		BODY,DIV,TABLE,THEAD,TBODY,TFOOT,TR,TH,TD,P { font-family:"Arial"; font-size:x-small }
		 -->
	</style>


removing "font-size:x-small" fixed the problem.

Comment 3

[Hashem Masoud]

(In reply to ian wood from comment #2)
Similar bugs: bug 591995 and bug 682438.

Comment 4

[Ludovic Hirlimann [:Usul]]

also worth looking at on http://www-archive.mozilla.org/editor/midasdemo/ if the issue is present there , then it's a core bug.

Comment 5

[ian wood]

(In reply to Ludovic Hirlimann [:Usul] from comment #4)
> also worth looking at on http://www-archive.mozilla.org/editor/midasdemo/ if
> the issue is present there , then it's a core bug.

Confirmed. http://www-archive.mozilla.org/editor/midasdemo/ has the same behaviour.

Further experimentation reveals that the offending style tag of the pasted html derives from the spreadsheets default style (even if another style is applied to the cell). imho that style tag should not be present.

Should this be posted as a LibreOffice bug?

Note: if a style is applied to a cell in Calc, that style is reflected in the pasted html as various html tags (<b>, <font> etc..) within the <td> of the pasted cell. In this case, the offending style tag (outside the pasted <table>) is still present.

Comment 6

[(no longer active)]

Yes, this is a LibreOffice bug.

Comment 7

[ian wood]

For those looking for a workaround, you can select the pasted text (which appears as a table), from the "Insert" menu selct "HTML...", then remove everything between "<style>" and "</style>" including the style tags themselves.

Comment 9

[ian wood]

(In reply to Ehsan Akhgari [:ehsan] from comment #6)
> Yes, this is a LibreOffice bug.

I'm not so sure, I had a look at the 'text/html' data on the clipboard. It contains a complete html page with the offending <style> tag in the <head>. This does not seem to be incorrect imho.

The styles that are there should *only* be applied to the pasted text, not to the whole document, as currently occurs. I know it's a pain, but they should either be applied as inline styles to the pasted tags (or something equivalent) or perhaps ignored.

Here is the contents of the 'text/html' clipboard data (the cell contents was 'tes' with default formatting):

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">

<HTML>
<HEAD>
	
	<META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=utf-8">
	<TITLE></TITLE>
	<META NAME="GENERATOR" CONTENT="LibreOffice 3.4  (Unix)">
	<STYLE>
		<!-- 
		BODY,DIV,TABLE,THEAD,TBODY,TFOOT,TR,TH,TD,P { font-family:"Arial"; font-size:x-small }
		 -->
	</STYLE>
	
</HEAD>

<BODY TEXT="#000000">
<TABLE FRAME=VOID CELLSPACING=0 COLS=1 RULES=NONE BORDER=0>
	<COLGROUP><COL WIDTH=86></COLGROUP>
	<TBODY>
		<TR>
			<TD WIDTH=86 HEIGHT=17 ALIGN=LEFT>tes</TD>
		</TR>
	</TBODY>
</TABLE>
</BODY>

</HTML>

Comment 10

[ian wood]

reopening this bug as LibreOffice behaviour seems to be ok.

Comment 11

[ian wood]

Please change the status of this bug to 'confirmed' or 'new' as had been done with the duplicate bug 648797.

Comment 12

[Ludovic Hirlimann [:Usul]]

(In reply to Ehsan Akhgari [:ehsan] from comment #6)
> Yes, this is a LibreOffice bug.

Ehsan is the person who knows the mozilla code for editor. If he says it's a libre office bug then it is.

Comment 13

[Mikhail T.]

The resolution makes no sense. There may be a bug in Office, but the style of the pasted PART of text can not affect the style of the entire composed document.

Comment 14

[(no longer active)]

Well, OK, yeah, we could fix this if we had support for scoped styles.

Comment 15

[Mikhail T.]

Perhaps, the "offending" style elements/attributes can be parsed out from the clipboard's contents in the mean time?

Comment 16

[(no longer active)]

(In reply to Mikhail Teterin from comment #15)
> Perhaps, the "offending" style elements/attributes can be parsed out from
> the clipboard's contents in the mean time?

That would be harder than just fixing bug 508725 I think.  :-)

Comment 17

[ian wood]

(In reply to Ehsan Akhgari [:ehsan] from comment #16)
> (In reply to Mikhail Teterin from comment #15)
> > Perhaps, the "offending" style elements/attributes can be parsed out from
> > the clipboard's contents in the mean time?
> 
> That would be harder than just fixing bug 508725 I think.  :-)

Currently, the "offending" style tag is being parsed out from the <head> of the pasted html and prepended to the contents of the pasted <body>. Depending on where in the code that is happening (eg: if it's not tangled up with other components etc..) perhaps it would be simple to not prepend the <style>?

I'm not sure how it is with html copied from other applications, but with LibreOffice, the <style> tag in the head derives from the 'Default' style. Any other applied styles appear inline within the <body> of the copied html (the style tag in the head is still present in this case). 

I think it would not be unreasonable to ignore this default style so that (in the absence such inline styles) the text appears according to the default style Thunderbird applies.

Comment 18

[(no longer active)]

We don't have any way to know where the style tag is coming from.  If we do ignore them, others will complain that the styles in their source document are not applied when pasting.

Comment 19

[ian wood]

(In reply to Ehsan Akhgari [:ehsan] from comment #18)
> We don't have any way to know where the style tag is coming from. If we do
> ignore them, others will complain that the styles in their source document
> are not applied when pasting.

I played around a bit with Writer as well: it's behaviour is inconsistent. Purely user defined styles appear to be provided inline whereas a style defined as "linked with" one of the default styles appear as a class defined in a style tag in the head. I imagine you've seen the likes of this before... If applications are inconsistent with their generation of clipboard html, then short of scoped styles or parsing (potentially broken) style tags it's hard to know what to do ):

then there's the issue that many mail clients don't support style tags (only inline styles), but I guess that's another story (:

Anyone looking for a workaround, refer to https://bugzilla.mozilla.org/show_bug.cgi?id=758999#c7

Comment 20

[Mark Hodge]

If you find this bug as irritating as I do, try this workaround (it works in Windows 7 x64 anyway):

Paste your LibreOffice Calc table into Thunderbird.

Click on the line immediately after the inserted table. Press shift-back arrow. Press delete. Tada! - the email goes back to normal size text everywhere :-)

YMMV, but this works every time for me.

Cheers,
Mark

Comment 21

[cris]

Regarding the workaround, you can simplify it further by simply clicking into the very end of the last cell in the table, and then pressing the DEL button on the keyboard.  On Ubuntu10 I was able to do as Mark Hodge explained in the post above, but without the need of pressing the shift button.

Comment 22

[Renato S. Yamane]

Hello?
Is there anyone taking a looking on this 2 years old bug?

Thanks,

Comment 23

[florian.henry]

Confirm bug is still there with Libre Office 5 and Thunderbirds 38.3.0 in Ubuntu 14.04.3.
And confirm the work-aournd with DEL works.
Any clue to know if this will be solve anytime ?

Comment 24

[Robert]

This is so annoying. Bug still exists with LibreOffice 5.1.4 and Thunderbird 45.3.0 in Ubuntu 16.04.

Comment 25

[Migs]

Just reporting existence of this bug while OpenOffice Calc 4.1.0 and Thunderbird 45.3.0 (upgraded to 45.30.0 in hopes that it will be resolved :( )
If the reported workaround doesn't work (placing the cursor at the very last cell/character of the newly created pasted table and press Del), then you need to remove the tags at the beginning of the pasted table by placing the cursor at the end of the previous paragraph before the table and also pressing the Delete (Del) key, the email text should revert back to normal again.

Comment 26

[Hans Deragon]

Confirming for Thunderbird 45.4.0, LibreOffice 5.2.3.2, Ubuntu 16.04 LTS Xenial Xerus.  Notice that while writing the email, the font size is normal everywhere (body text + html table text).  However, once sent, the email received makes use of a small way too small.  The email in the sent box also shows with small fonts, looking exactly like the received email.

Comment 27

[Hans Deragon]

Still happening on some emails sent, but not all. Thunderbird 60.8.0 (64-bit), LibreOffice 6.3.1.2, Ubuntu 19.04. Looking at the source code of the email, I wonder if it not a problem with the zoom changing automatically for showing more on the view pane. But I am not an expert regarding TB.

Comment 28

[bugzilla]

Thunderbird 78.13.0 (64-bit), Ubuntu.

This stuff gets inserted:

"<style type="text/css">body,div,table,thead,tbody,tfoot,tr,th,td,p { font-family:"Arial"; font-size:x-small } ..."

Format -> Size from the menu shows Medium, and changing the font size there has no effect. Everything is still x-small.

Got here from this 11 year old bug: https://bugzilla.mozilla.org/show_bug.cgi?id=648797

Comment 29

[Zurd]

This is really annoying and a waste of time to try to format it back like it was before. Bug was opened 12 years ago! :(

Issue is still happening with LibreOffice 6.4.7.2 and Thunderbird 102.4.2 and so easy to reproduce; just copy cells from LibreOffice Calc to Thunderbird when you reply to an email. Everything is messed up.

The fix from Mark still works but no need to click, after pasting the cells: DOWN ARROW then SHIFT+LEFT ARROW then DELETE

Comment 30

[Zurd]

You'd think that two open source software would work well together but that is not the case.

My fix is still the fastest way around: paste the cells like CTRL-V, then DOWN ARROW once then SHIFT+LEFT ARROW then DELETE

However, I just found out, make sure that the copied cells are not the last lines in the emails, else it will not work. Press ENTER a couple of times and paste above.

Comment 31

[Giuliano Lotta]

Could it be possible to manage the copied html from Libreoffice:

1. wrapping the content in one new <div>, so to isolate the new pasted html
2. get the original libreofffice <style> contained in the <head>, and move it as a <style> for the new <div>

the idea is to keep the pasted style, without applying it to the whole message.

In case there is no <head> with a <style> (eg: no libreoffice clipboard source) in the clipboard content , the paste is performed just injecting the clipboard content in a new <div>

May it work ?

Comment 32

[Renato S. Yamane]

This is an 11 years old bug, not assigned. There is no developer following this issue.
Forget it. It will never be fixed.
Consider the workaround on Comment #20 as the only possible solution.

Comment 33

[bugzilla]

An excellent idea, by Giuliano Lotta, in Comment 31.
https://bugzilla.mozilla.org/show_bug.cgi?id=758999#c31

Comment 34

[nicod]

Thunderbird 102, Libre Office 7.4, the bug is still there and very upsetting...
Thanx for the workaround, but it's a bit tricky for non tech people :-(

Comment 35

[fxdeltombe]

Thunderbird 140, LibreOffice 25, the bug is still ongoing...

Comment 36

[Renato S. Yamane]

This is a 13 years old bug.
There is no developer following it.
Try the Comment #20 workaround and I guess worth to open a new bug report. This one is dead.

Comment 37

[Zurd]

Bug has a status OPEN, it's not dead. Making a new bug report will just make a duplicate of this one.

I found a really nice fix but I have no idea if it will cause a regression issue. I am not a Thunderbird developer. The patch below is from ChatGPT.

Fix Thunderbird Spreadsheet Paste Font Size Bug on Linux

Problem : When pasting cells from Excel / LibreOffice Calc into a Thunderbird email, the pasted HTML can bring bad font-size styling and make the whole email text appear smaller. This patch strips spreadsheet font-size junk before Thunderbird inserts the HTML.

1. Backup
   sudo cp /usr/lib/thunderbird/omni.ja /usr/lib/thunderbird/omni.ja.bak

2. Extract
   mkdir /tmp/tbpatch
   cd /tmp/tbpatch
   unzip /usr/lib/thunderbird/omni.ja

3. Edit
   xed chrome/messenger/content/messenger/messengercompose/MsgComposeCommands.js

Find:

// Ok, we have html content to paste.
const html = dataTransfer.getData("text/html");
const doc = new DOMParser().parseFromString(html, "text/html");

It is at line 4439. Add this after:

// Fix spreadsheet paste font-size pollution.
const hasFontJunk =
  doc.querySelector("[style*='font-size']") ||
  doc.querySelector("font[size]");

if (hasFontJunk) {
  e.preventDefault();

  for (const el of doc.querySelectorAll("[style]")) {
    if (el.style.fontSize) {
      el.style.fontSize = "";
    }

    if (!el.getAttribute("style")?.trim()) {
      el.removeAttribute("style");
    }
  }

  for (const font of doc.querySelectorAll("font[size]")) {
    font.removeAttribute("size");
  }

  GetCurrentEditor().insertHTML(doc.body.innerHTML);
  return;
}

4. Repack
   cd /tmp/tbpatch
   zip -r9 ../omni.ja *

5. Replace
   sudo cp ../omni.ja /usr/lib/thunderbird/omni.ja

6. Clear cache
   rm -rf ~/.cache/thunderbird ~/.thunderbird/*/startupCache

7. Start Thunderbird and test

To rollback:
sudo cp /usr/lib/thunderbird/omni.ja.bak /usr/lib/thunderbird/omni.ja

Notes:
Thunderbird updates will overwrite this patch.

This only modifies HTML paste containing font-size junk, so normal paste behavior should mostly remain untouched.

Comment 38

[Renato S. Yamane]

(In reply to Zurd from comment #37)

Bug has a status OPEN, it's not dead. Making a new bug report will just make a duplicate of this one.

In 13 years, not a single developer jumped in. So this bug report is dead. It's in a limbo.

It was reported on Thunberbird 12, we are now on version 140.

Open a new bug report to Thunderbird 140 and fingers crossed that someone will look at it. Doesn't worth to keep insisting on this one.