Bug 52547 - New Firefox image clipboard causes "paste as link" in LibreOffice - paste directly is preferred
Summary: New Firefox image clipboard causes "paste as link" in LibreOffice - paste dir...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: framework (show other bugs)
Version:
(earliest affected)
3.6.0.0.beta2
Hardware: Other All
: high normal
Assignee: Andrzej Hunt
URL:
Whiteboard: target:4.3.0 target:4.2.3 target:4.1.6
Keywords:
Depends on:
Blocks:
 
Reported: 2012-07-26 14:39 UTC by Dave Richards
Modified: 2014-03-09 17:41 UTC (History)
11 users (show)

See Also:
Crash report or crash signature:


Attachments
Now offering two items, URL an bitmap (248.17 KB, image/png)
2012-07-26 14:39 UTC, Dave Richards
Details
Image is a link to the Internet and not a bitmap. (336.22 KB, image/png)
2013-11-18 13:20 UTC, Dave Richards
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dave Richards 2012-07-26 14:39:47 UTC
Created attachment 64741 [details]
Now offering two items, URL an bitmap

Prior to Firefox 12, when you right-mouse clicked on an image and selected "Copy Image" the bitmap was placed into the clipboard.  This worked perfectly in OpenOffice/LibreOffice. With Firefox 12 and higher, when you select "Copy Image" the URL and bitmap are both placed into the clipboard.  In LibreOffice, when you select "Paste Special" the two types are displayed.  However when you paste it uses the URL and embeds the image into the document.  Regular users cannot immediately see the difference, however it's preferable to always use the bitmap when available and store the image inside the document.  This builds a self contained document that can be viewed even when not connected to the Internet.

We are requesting that the paste clipboard by default always use a bitmap if it's available.

Attaching a shot showing the clipboard as offered by Firefox.
Comment 1 Dave Richards 2012-07-26 14:41:44 UTC
Here is some more information:

http://support.mozilla.org/en-US/questions/926093?page=3

Firefox 12 added new formats to the clipboard when you copy an image. Unfortunately, some applications were choosing a plain text URL rather than the bitmap (image data), so the change in Firefox 13 is to remove the plain text URL from the clipboard.

However, both Firefox 12 and Firefox 13 include some HTML code on the clipboard, to embed the image. This is needed to be able to paste images into Gmail messages, which was the whole point of making the change in Firefox 12.
Comment 2 Marco Menardi 2012-09-28 22:46:54 UTC
I can confirm this, does not happen with Firefox 10 in my debian sid, but happens in Kubuntu 12.04, that has Firefox 15, with Libo 3.5.x and 3.6.x.
I've noticed this because I've a ltsp installation in a school with limited internet bandwidth. When students find an image with FF and copy and paste in LibreOffice, Libo process pushes CPU in the server at 100% for long time (i.e. 10-20 seconds or more) and the student thinks that the computer or Libo is frozen. Being a LTSP thin client setup, if more do this the server is put on it's knee.
As workaround they could use "paste special" and select the second item: "paste bitmap", but being young children (6-10 years old) I think will be easy they don't do :).
To increase the problem, if in a document you have the link and want to break it so to have the image as bitmap, when you select Edit -> Links, even if you see the image, pressing the break button reloads the image from internet (I think this should not be the case, since it already has it).
Comment 3 mal 2012-10-06 13:40:23 UTC
This is a really horrible bug/feature. I have 400 machines with LO and the students are so used to just doing a copy/paste when they used Word trying to get them to use Paste Special in LO is a nightmare.

It still happens in 3.6.1

Ta

M
Comment 4 Jorendc 2012-12-14 17:43:31 UTC
I can confirm with Mac OSX 10.8.2; LibreOffice 3.6.4.3 (Build-id: 2ef5aff); Dutch UI;

When I paste 'normaly' -> image pasted as HTML
When I 'Paste Special' -> window will pop up and I have to choose.
Comment 5 Jorendc 2012-12-14 17:57:28 UTC
When I copy an Image from Safari (right click -> copy image) and paste it 'normaly' in LibreOffice -> only the URL is pasted; NO image!
When I 'Paste Special' -> I can choose between 'Bitmap' and 'Text without markup' (=roughly translated).

Tested with Safari Version 6.0.2 (8536.26.17) and Mac OS X 10.8.2;
LibreOffice Version 3.6.4.3 (Bouw-id: 2ef5aff). Dutch Language pack.



PS: in Comment #4 I tested it with FF 17.0.1 (Dutch)
Comment 6 Johan van der Knijff 2013-01-03 12:16:48 UTC
I came across this issue as well after the following report by a user of OpenOffice (which has the same problem):  

http://fileformats.wordpress.com/2012/12/30/openoffice/

As another user already commented, this strikes me as a really nasty and serious bug, particularly since visually LO doesn't give any clue whatsoever that what's pasted here is a link rather than the actual image data! 

Once something happens to the linked image in its original (remote) location (e.g. it is removed or changed), this will have an immediate impact on the LO document. So for some documents the implications of this could be pretty dramatic.
Comment 7 Cor Nouws 2013-01-07 21:47:39 UTC
IIRC, in the past the behaviour was paste as link, but directly embedded in the document, as was the case recent, definitely is better
Comment 8 Marco Menardi 2013-11-17 10:44:27 UTC
This bug is still present in the 4.x, and is causing major issues in all the 4 school where I've deployed LiBo (around 300 users).
As I wrote, teachers are not able even to understand the issue and do "paste special", children are young and in any case they are used with other tools that "just work".
To me looks a trivial fix (of course, without knowing the code...), could please someone have a look at it?
Teachers scream because "GNU/Linux does not work, computer freeze, internet does not work" and every possible negative observation. You know how hard is push toward software libre...
thanks a lot
Comment 9 retired 2013-11-17 12:37:33 UTC
Setting importance to high, since the current behavior concerns many installation and from what I read is leading to great confusion amongst users.

Tested on OS X 10.9 and FF 25.0.1. 

Visited https://bugs.freedesktop.org/attachment.cgi?id=64741 then right-click "copy image".

Pasting in LO Version: 4.2.0.0.alpha1+
Build ID: 868103846b9b32bfecd77c08055fdca69d0265c2
TinderBox: MacOSX-x86@48-TDF, Branch:master, Time: 2013-11-14_23:51:46
-> results in http://cl.ly/image/243r0U0A3T01
-> then wait a few seconds and http://cl.ly/image/251r3k3p3d3E

WORKSFORME (fixed in master build)

Pasting in LO Version: 4.1.3.2
Build ID: 70feb7d99726f064edab4605a8ab840c50ec57a

also works


Setting to WORKSFORME.

To all concerned in this bug: please update Firefox and LO to the latest stable release and you should be fine.
Comment 10 Thomas van der Meulen 2013-11-17 12:47:37 UTC
I can verify that is works on with FireFox 25 and LibreOffice 4.2 alpha 1
after a few seconds the image loads.
Comment 11 Marco Menardi 2013-11-17 15:31:03 UTC
(In reply to comment #9)
> Setting importance to high, since the current behavior concerns many
> installation and from what I read is leading to great confusion amongst
> users.
> 
> Tested on OS X 10.9 and FF 25.0.1. 
> 
> Visited https://bugs.freedesktop.org/attachment.cgi?id=64741 then
> right-click "copy image".
> 
> Pasting in LO Version: 4.2.0.0.alpha1+
> Build ID: 868103846b9b32bfecd77c08055fdca69d0265c2
> TinderBox: MacOSX-x86@48-TDF, Branch:master, Time: 2013-11-14_23:51:46
> -> results in http://cl.ly/image/243r0U0A3T01
> -> then wait a few seconds and http://cl.ly/image/251r3k3p3d3E
> 
> WORKSFORME (fixed in master build)
> 
> Pasting in LO Version: 4.1.3.2
> Build ID: 70feb7d99726f064edab4605a8ab840c50ec57a
> 
> also works
> 
> 
> Setting to WORKSFORME.
> 
> To all concerned in this bug: please update Firefox and LO to the latest
> stable release and you should be fine.

You are not testing the correct behavior!!!
I've tested 4.1.3.2, and behaves as you describe, but is what should NOT do, it's pasting the LINK and fetching from internet the image (that's why you have a placeholder for the image and then you see the image in the doc, it's just a "live" link).
Instead the correct behavior with a simple "paste" is that must paste the image from the clipboard, so put it immediately in writer (no delay) and have it "embedded" and not as a link.
That is what needs to be fixed, so is still open for me.
Comment 12 Dave Richards 2013-11-18 13:19:17 UTC
Confirmed this is still not working in LO 4.2 (Alpha).  File is being linked instead of the bitmap being placed into the document.  This does indeed cause a lot of frustration for end users and there is no way to explain this to them.  

Linked documents cause lots of problems when documents are reopened, often they are slow in opening and make LO look like it's deadlocked.  If said document is opened where this is no Internet connection, document appears broken and users perceive that LO not working.

Attaching screenshot.
Comment 13 Dave Richards 2013-11-18 13:20:00 UTC
Created attachment 89407 [details]
Image is a link to the Internet and not a bitmap.
Comment 14 mal 2013-11-18 13:34:04 UTC
The short version of this conversation is LO should preferentially use the bitmap if several options are on the clipboard not just the first in the list.
See bug 55735 ( see comment 5 ) and probably bug 65410 also

This is really nasty and is the single biggest complaint we have 
from our students.

M
Comment 15 Commit Notification 2014-02-12 11:09:14 UTC
Andrzej Hunt committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=c47db038f98aaf7aec3cbe57c4e5683591afa23e

fdo#52547 SOT: Prefer embedding image data to embedding linked image.



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 16 Dave Richards 2014-02-12 12:57:31 UTC
Can this be backported to 4.2 easily?  This has significant impact for us, and it would be nice to get this into production faster.
Comment 17 Marco Menardi 2014-02-28 11:48:08 UTC
Me too asking to backport to 4.2, that will solve the big *big* problem we still have at school. The fix seems really no risky.
Comment 18 Commit Notification 2014-03-01 13:26:41 UTC
Andrzej Hunt committed a patch related to this issue.
It has been pushed to "libreoffice-4-2":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=91a55de7be6a23685a875517495c1af67f3a8b60&h=libreoffice-4-2

fdo#52547 SOT: Prefer embedding image data to embedding linked image.


It will be available in LibreOffice 4.2.3.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 19 mal 2014-03-07 10:42:49 UTC
Can this be back ported to 4.1.n LibreOffice

I have contacted the maintainer at openSuse and 13.1
is only going to have 4.1.n in it's ( long ) lifetime

I'm guessing 4.2 will be in 13.2. We however are likely
to stay with 13.1 but this fix would be a huge benefit
to our students

Ta

Mal
Comment 20 Commit Notification 2014-03-09 17:41:59 UTC
Andrzej Hunt committed a patch related to this issue.
It has been pushed to "libreoffice-4-1":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=7ec57838ae2cec6e9b331cfb4fba49c086af1af5&h=libreoffice-4-1

fdo#52547 SOT: Prefer embedding image data to embedding linked image.


It will be available in LibreOffice 4.1.6.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.