Issue 122920 - Image pasted from certain browsers is black
Summary: Image pasted from certain browsers is black
Alias: None
Product: General
Classification: Code
Component: code (show other issues)
Version: 4.0.0
Hardware: PC Windows, all
: P3 Major (vote)
Target Milestone: 4.0.1
Assignee: Armin Le Grand
QA Contact:
Keywords: regression
: 122842 123080 (view as issue list)
Depends on:
Reported: 2013-07-31 22:00 UTC by Steve Cooper
Modified: 2017-05-20 10:34 UTC (History)
11 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---
jsc: 4.0.1_release_blocker+

Result on rev. 1518667.jpg (110.15 KB, image/jpeg)
2013-09-05 10:32 UTC, fanyuzhen
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description Steve Cooper 2013-07-31 22:00:43 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.
Comment 1 Ariel Constenla-Haile 2013-07-31 22:03:49 UTC
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?
Comment 2 Steve Cooper 2013-07-31 22:24:56 UTC
The bug reliably occurs with Firefox. For example, all of the following images paste into Impress as black rectangles:

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.
Comment 3 Ariel Constenla-Haile 2013-07-31 22:38:25 UTC
Not reproducible on Linux 64 bit
Reproducible on Windows 7 64 bit

Probably the same root cause as Bug 122842
Comment 4 Ariel Constenla-Haile 2013-07-31 22:39:28 UTC
Adapted summary and component.
This is an application-wide bug, happens also in Writer, for example.
Comment 5 Daiwe01 2013-08-01 13:14:38 UTC
WinXP SP3 using posted examples:
Confirmed in Impress.
Works as expected in Writer.
Comment 6 rebowenjr 2013-08-06 19:01:46 UTC
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, 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.
Comment 7 Regina Henschel 2013-08-19 21:55:50 UTC
It seem to happen between r14252200 (ok) and 1439888 (fail).
There has been r1431512 with a lot of graphic changes to fix bug 121504.
Comment 8 Regina Henschel 2013-08-21 18:13:10 UTC
*** Issue 123080 has been marked as a duplicate of this issue. ***
Comment 9 Regina Henschel 2013-08-21 23:29:13 UTC
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.
Comment 10 Kay 2013-08-21 23:54:25 UTC
Not reproducible with with AOO4 in Linux-32 w/ FF 23.

I just used a solid white background -- nothing fancy in my test slide.
Comment 11 Armin Le Grand 2013-08-28 13:19:02 UTC
ALG: I can reproduce this one, taking a look...
Comment 12 Armin Le Grand 2013-08-28 15:30:20 UTC
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. it works. Need to debug a OOO3.4.1 to look for differences...
Comment 13 Armin Le Grand 2013-08-29 09:27:52 UTC
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...
Comment 14 Armin Le Grand 2013-08-29 11:23:19 UTC
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.
Comment 15 Armin Le Grand 2013-08-29 11:26:23 UTC
ALG: Comitted to trunk as r1518592, waiting for AOO401 flag
Comment 16 SVN Robot 2013-08-29 11:29:02 UTC
"alg" committed SVN revision 1518592 into trunk:
i122920 Corrected some minor aspects of DIB clipboard exchange format
Comment 17 jsc 2013-08-29 11:34:05 UTC
approve showstopper request
Comment 18 Armin Le Grand 2013-08-29 12:06:45 UTC
ALG: Checked solution on Linux, works well.
Comment 19 Armin Le Grand 2013-08-29 12:19:50 UTC
ALG: Checked in and comitted to AOO401
Comment 20 SVN Robot 2013-08-29 12:26:32 UTC
"alg" committed SVN revision 1518623 into branches/AOO401:
i122920 Corrected some minor aspects of DIB clipboard exchange format
Comment 21 jsc 2013-08-29 13:47:39 UTC
approve showstopper request again
Comment 22 Armin Le Grand 2013-08-29 13:50:35 UTC
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...
Comment 23 Armin Le Grand 2013-08-29 15:51:35 UTC
ALG: Oops, ignore last comment, it was for #123003#, sorry
Comment 24 jsc 2013-08-30 09:12:32 UTC
set target milestone
Comment 25 Armin Le Grand 2013-09-03 10:36:28 UTC
ALG: Corrected owner
Comment 26 Armin Le Grand 2013-09-04 13:21:43 UTC
*** Issue 122842 has been marked as a duplicate of this issue. ***
Comment 27 fanyuzhen 2013-09-05 10:32:34 UTC
Created attachment 81457 [details]
Result on rev. 1518667.jpg
Comment 28 fanyuzhen 2013-09-05 10:51:25 UTC
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.