Apache OpenOffice (AOO) Bugzilla – Issue 122920
Image pasted from certain browsers is black
Last modified: 2017-05-20 10:34:00 UTC
Pasting an image into Impress 4.0.0 from Firefox 22.0 and IE 8 fails. Chrome 28.0.1500.95 appears to work. When pasting from Firefox, the image in Impress is sized correctly, but completely black. (Confirmed on Windows XP 32-bit and Windows 7 64-bit.) When pasting from IE 8, the image does not appear on the slide. Impress evidently ignores the paste request, as the undo menu item does not update to "Undo Paste". (Confirmed on Windows XP 32-bit.) In both these cases, pasting the same image into other applications (PowerPoint, MS Paint, etc.) work as expected. This operation also worked in OO 3.4.1. As a workaround, it is possible to first paste the image into a third application (such as MS Paint), copy it from MS Paint, and paste it into Impress.
Does it happen with any image? Can you share a link to an image in order to reproduce it, explaining how you copy it from the browser?
The bug reliably occurs with Firefox. For example, all of the following images paste into Impress as black rectangles: http://www.openoffice.org/images/AOO_logos/AOO4_website_logo.png http://upload.wikimedia.org/wikipedia/commons/thumb/9/9a/PNG_transparency_demonstration_2.png/280px-PNG_transparency_demonstration_2.png http://personal.psu.edu/tao5048/JPG.jpg The IE 8 bug is more difficult to reproduce. It seems to occur when IE 8 misinterprets a PNG image as a bitmap image. I don't have a public URL to share. However, as I said, even in this case, Impress 3.4.1 had no problem pasting the image. To copy it from Firefox, I do the following: 1. Start Impress 4.0.0. 2. Start Firefox. 3. Visit any of the above URLs. 4. Right-click the image, and choose "Copy Image" from the context menu. 5. Switch to Impress and choose "Paste" from the Edit menu. Regarding step 5, I also tried using Ctrl-V, which generated the same results. Also, "Paste Special..." generates the same results.
Not reproducible on Linux 64 bit Reproducible on Windows 7 64 bit Probably the same root cause as Bug 122842
Adapted summary and component. This is an application-wide bug, happens also in Writer, for example.
WinXP SP3 using posted examples: Confirmed in Impress. Works as expected in Writer.
Pasting image from Firefox or IE 8 to Calc or Writer is black. AOO 4.0.0 Windows 7 64 bit First found with a Paste Special as Bitmap into Calc from movie coverart image copied from Rottentomatoes.com, and tried from several other sources and the same result, a solid black block the size of the image. Existing coverart in the same spreadsheet was OK.
It seem to happen between r14252200 (ok) and 1439888 (fail). There has been r1431512 with a lot of graphic changes to fix bug 121504.
*** Issue 123080 has been marked as a duplicate of this issue. ***
I have made a build of r1439808 and see the error already there. So the reason is not the commit r1439888, which had made large graphic changes too.
Not reproducible with with AOO4 in Linux-32 w/ FF 23. I just used a solid white background -- nothing fancy in my test slide.
ALG: I can reproduce this one, taking a look...
ALG: Strange; I really get a 0xff-filled CF_DIB file in the direct windows call m_rDataObject->GetData in CDOTransferable::getClipboardData and it gets correctly interpreted as Bitmap/BitmapEx. I also see that with other apps (e.g. paint.net) it works. Need to debug a OOO3.4.1 to look for differences...
ALG: Found some more hints; it has to do with the DIB format stuff and the DIBV5 extensions. At import, when Alpha may be used, TCMask is disabled. This leads to shifting all stuff to null which makes all black. Checking solutions...
ALG: Three changes: - On load, do always set RGBMask values (init nRMask/nGMask/nBMask) since these are potentially used - On load, check if Alpha was used, if not, create only Bitmap - On save, init nV5Intent (see BITMAPV5HEADER docu on the web) to LCS_GM_IMAGES (was LCS_GM_ABS_COLORIMETRIC before) which creates better exchange with e.g. Paint.NET Checked these changes, work as expected. Probably the same reason as for #122842#, preparing commit to trunk and requesting AOO401 flag.
ALG: Comitted to trunk as r1518592, waiting for AOO401 flag
"alg" committed SVN revision 1518592 into trunk: i122920 Corrected some minor aspects of DIB clipboard exchange format
approve showstopper request
ALG: Checked solution on Linux, works well.
ALG: Checked in and comitted to AOO401
"alg" committed SVN revision 1518623 into branches/AOO401: i122920 Corrected some minor aspects of DIB clipboard exchange format
approve showstopper request again
ALG: It depends currently on the DragSingles setting which is part of the user settings; this is the flag which switches when entering/leaving single point mode. The error can be reproduced with a new doc when switching to PointEditMode and then working on a text object. The test document has this flag set in the user settings. Of course this sould be independent from PointEditMode; checking sources...
ALG: Oops, ignore last comment, it was for #123003#, sorry
set target milestone
ALG: Corrected owner
*** Issue 122842 has been marked as a duplicate of this issue. ***
Created attachment 81457 [details] Result on rev. 1518667.jpg
It's verified fixed in build AOO401m2(Build:9711) - Rev. 1518667 on Firefox 17 ESR, I don't have IE 8 and will try to look for one.