| Summary: | New Firefox image clipboard causes "paste as link" in LibreOffice - paste directly is preferred | ||
|---|---|---|---|
| Product: | LibreOffice | Reporter: | Dave Richards <drichard> |
| Component: | framework | Assignee: | Andrzej Hunt <andrzej> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | high | CC: | andrzej, arnaud.versini, cno, heinzlesspam, jbfaure, johan.vanderknijff, jorendc, malcolm, mmenaz, pje335-lo, simon.marshall |
| Version: | 3.6.0.0.beta2 | ||
| Hardware: | Other | ||
| OS: | All | ||
| See Also: | https://issues.apache.org/ooo/show_bug.cgi?id=37652 | ||
| Whiteboard: | target:4.3.0 target:4.2.3 target:4.1.6 | ||
| i915 platform: | i915 features: | ||
| Attachments: |
Now offering two items, URL an bitmap
Image is a link to the Internet and not a bitmap. |
||
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. 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). 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 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. 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) 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. IIRC, in the past the behaviour was paste as link, but directly embedded in the document, as was the case recent, definitely is better 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 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. I can verify that is works on with FireFox 25 and LibreOffice 4.2 alpha 1 after a few seconds the image loads. (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. 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. Created attachment 89407 [details]
Image is a link to the Internet and not a bitmap.
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 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. 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. 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. 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. 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 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. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
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.