Pasting directly from a Google Image search causes Libre Office Writer to crash/hang. Reproduce: Search Google for image. Copy the image from the grid (don't click on the image to load it) Paste into Writer. Libre Office will hang. If you click on the image, and copy the enlarged version, it pastes fine. If you copy the thumbnail image in Impress, it pastes fine.
Thanks for reporting! I can't reproduce a crash, but I can confirm a tedious slowness using Linux Mint 14 x64 with LibreOffice 4.0.0.3 rc3. Also the image isn't pasted good after the freeze (15 seconds). Therefore I mark this bug as NEW. Following [1] I mark this as 'Major highest' (highest because the fact the image isn't pasted correctly as well). Kind regards, Joren [1] https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart.jpg
More information - it only happens when pasting from Chromium or Google Chrome. Pasting from Iceweasel works fine. Ollie
I can confirm slowness with Firefox 23 on Master(Build ID: 4cd9024db1898176ed2dc06dfe36a2c71213bb02) Also I have this console output. http://pastebin.ca/2459278 Best, Efe Gürkan
Created attachment 92029 [details] Screenshot
LO 4.1.2.3 on Xubuntu 12.04 64bit with Mozilla 26.0. Trying to copy and paste a picture from the grid. I can confirm slowness and that LO hangs. The picture isn't really pasted. There's only a picture frame (see attached scrennshot). If I try to scroll the document even the whole system hangs for a few seconds. In one case I had to do a restart over the console, because xfce hangs completely. If I scroll down, so the picture frame isn't to see anymore, it works. If I scroll up again, so the picture would be visible again, LO and systems hangs (high harddisk and cooler activity).
(This is an automated message.) LibreOffice development currently prioritizes bugs with the so called MAB (most annoying bugs) -- as this bug has not run through that process (including writing a short rationale for this bug being a candidate and other who are watching the tracker bug silently approving that rationale etc.) its priority is set to high. Note this is effectively no change in the urgency assigned to this bug, as we are currently not making a difference between high and highest and severity is untouched. You can find out more about MABs and how the process works by contacting libreoffice qa on irc: http://webchat.freenode.net/?channels=libreoffice-qa The QA wiki page also gives you hints on how to get in contact with the team (if IRC fails you, your next best choice is the mailing list): https://wiki.documentfoundation.org/QA
I've just seen this mentioned on the mailing list: http://listarchives.libreoffice.org/global/users/msg36731.html This mentions LibreOffice Writer versions from 3.x to 4.2 on Ubuntu (10.04 to 13.1). I can confirm this in LibreOffice Writer 4.0.4.2, copying from Mozilla SeaMonkey 2.23, on Windows Vista. Copying static images from a couple of other websites was no problem, so it seems to be partly to do with the way Google images search works. Calc, Draw and Impress do not appear to be affected. To reproduce (until Google change their image search, at least): 1. Navigate browser to https://www.google.com/search?tbm=isch&q=random 2. Right click on one of the result images and select "Copy Image" 3. From LibreOffice Writer, Edit > Paste 4. LibreOffice Writer shows an outline for the image, then hangs Copying from other websites into Writer, it looks like Writer gets a link to the image, then downloads it itself. However, the URL included when copying an image from a Google image search isn't a link to an image on a web server (it begins "data:" rather than "http:") - I guess the image data is obtained via JavaScript or JSON or something in the web browser, but that link won't then work for another application. Not good that it hangs LibreOffice Writer though! I'm not sure about Linux, but on Windows a "copy" operation can put data on the clipboard in several formats, and the "paste" operation can then use any one of those (usually a default, with "paste special" giving the user a choice). Copying an image from the web browser appears to place data on the clipboard in HTML and bitmap formats, where the HTML includes a link to the image as well as alt text etc. It looks like Writer uses the HTML by default and attempts to download the image data itself, while Draw and Impress use the image data from the clipboard. Presumably Writer does something useful with the other HTML attributes which Draw and Impress don't, but looks like it needs to handle "data:" links (and perhaps other cases) more gracefully. Writer does not hang if using Paste Special > Bitmap, to use the bitmap data from the clipboard rather than the HTML - but that doesn't exactly help anyone who uses the default "Paste" and finds Writer hangs. Mark.
Sorry - that direct link to Google doesn't seem to work to reproduce, as that _does_ include https: URLs to the images. Revised steps to reproduce (Google results include data: URLs to images): 1. Navigate browser to http://images.google.com/ 2. Type "random" (or anything else) in the search box and submit the search 3. Right click on one of the result images and select "Copy Image" 4. From LibreOffice Writer, Edit > Paste 5. LibreOffice Writer shows an outline for the image, then hangs
"However, the [data:] URL included when copying an image from a Google image search ... won't then work for another application." That wasn't quite true, as the image data is encoded in the data: URL itself. (When claiming it wouldn't work in another application I was thinking of the cid: URLs used in HTML email for images attached to the email, which wouldn't be available to other applications being passed the URL). Still, it appears that something about these data: URLs is what hangs LibreOffice Writer.
Could you retry with 4.2.0.4? I can not reproduce this problem under OSX and LO 4.2.0.4. Right click image in browser, copy image, go to writer, paste, all good.
Just reproduced with LO 4.2.0.4 on Windows Vista, copying the image from SeaMonkey 2.23. Also tried copying from Internet Explorer 9.0.8112.16421 and Google Chrome 32.0.1700.107, with the same results. After a bit more experimenting, Writer doesn't actually hang completely, but becomes so slow as to be unusable. After pasting, the actual image doesn't appear (only a placeholder), and mouse clicks or typing takes about 25-60 seconds to respond. Typing "abcd", it takes 25 seconds for the "a" to appear, then after another 25 seconds "bcd" appears. Google seems to behave differently depending on browser capabilities. It may have presented you with a page of images with http: rather than data: URLs if, for example, JavaScript is disabled in the browser. It seems to be the data: URLs which cause LO Writer problems. I'll try to come up with a testcase which at least doesn't depend on Google's behaviour. I don't know if the clipboard might work differently under OSX, so it may be worth trying Paste Special and explicitly selecting HTML format, in case that's not the default. Or maybe the problem doesn't affect OSX, only Windows and (based on other comments) Linux builds.
Created attachment 93664 [details] Testcase containing an image which triggers the problem and some which don't Attached testcase is a HTML document. Opening this document in a web browser, copying the top image, and pasting it into Writer (using HTML format) reproduces the problem seem attempting to copy from Google image search results - Writer becomes very slow to respond. This top image is a JPEG image included as a data: URI copied from Google image search results (the original image is under a Creative Commons license, so hopefully no problem with using in this testcase). The second image is a conventional reference to an image on Google's servers (so may stop working at some point). Copying and pasting this image into Writer does NOT produce a problem. This file contains the same data as decoding the data: URI produces, so doesn't look like the problem is with the image data itself. The third image was my attempt at producing a testcase entirely independent of Google. It is a JPEG image, encoded into a data: URI. However, copying and pasting this image into Writer does NOT produce the problem - so it seems not to be /all/ data: URIs which cause a problem... The image is not displayed (OK, so Writer possibly doesn't support data: URIs) but at least it doesn't become almost unresponsive. It's not simply a matter of the size of the image/URI - this third image which does not cause a problem is actually larger than the one from Google which does cause a problem. Opening this document directly in Writer (as opposed to copying and pasting images from a web browser) produces somewhat erratic results. Writer hangs for tens of seconds when first displaying the document. Scrolling the top image placeholder out of view and back into view also hangs for tens of seconds. It then seems to be responsive as usual, typing text is fine, but then undoing that typing (Ctrl-Z or Edit > Undo) hangs for several seconds again - but only if the placeholder for that top image is in view. It seems that something about the images generated by Google image results and encoded as data: URIs upsets Writer, while the same image accessed from a https: URI does not cause a problem, neither do other images which are encoded as data: URIs...
I have my own web application written on RoR and I experience the same problem. The standard way of doing it on rails is to use "send_data" method: send_data @mypicture.attachment, :filename => @mypicture.filename, :type => "image/png" , :disposition => "inline" The response headers as below: HTTP/1.1 200 OK Server: nginx Date: Wed, 12 Feb 2014 09:09:44 GMT Content-Type: image/png Connection: keep-alive Keep-Alive: timeout=20 Content-Disposition: inline; filename="test.png" Content-Transfer-Encoding: binary Cache-Control: private X-UA-Compatible: IE=Edge ETag: "98fa6263bc3bba108e332e0696c53470" X-Request-Id: 3c3fc2493268c96d8c5c737ab13d9f06 X-Runtime: 0.091414 Content-Length: 243515
Ubuntu 14.04 LO 4.3.0.4 WORKSFORME All three images from https://bugs.freedesktop.org/attachment.cgi?id=93664 do copy paste without crash, hang, slowness or other issues. If this persists for you with LO 4.3.0.4 or newer, please re-open.
Just tried using: - Windows Vista - LibreOffice Writer 4.3.0.4 Copying images from: - Mozilla SeaMonkey 2.26.1 - Internet Explorer 9.0.8112.16421 - Google Chrome 36.0.1985.143 Also tried opening the HTML file directly in LibreOffice. No crash, hang, slow response, etc. in any combination tried, so looks like it's been fixed at some point. Although the web browsers have also been updated, I can still reproduce using the newer browsers and old LibreOffice 4.0.4.2, so it does appear to be a change in LibreOffice which has resolved the issue. Note that LO 4.3.0.4 appears to paste as bitmap rather than HTML by default, when a single image has been copied from a web page, so need to use paste special and choose HTML format (or HTML format without comments) to test this issue. There are some remaining quirks with the images from attachment 93664 [details], but those are not the subject of this issue: - First image (data: URI from Google image search) comes out much smaller (2cm x 1cm) when pasted as HTML or opening the HTML file directly in LO; Format > Image > Original Size sets it to the correct size. - Second image (https: URI) comes out OK when pasted as HTML, but much smaller (2cm x 1cm) when opening the HTML file directly in LO; Format > Image > Original Size sets it to the correct size. - Third image (custom data: URI) shows "Read-Error" in place of the image when pasted as HTML or opening the HTML file directly in LO.