Don't decode AND mask for an icon that already has alpha information

Source/platform/image-decoders/bmp/BMPImageReader.cpp

Index: Source/platform/image-decoders/bmp/BMPImageReader.cpp
diff --git a/Source/platform/image-decoders/bmp/BMPImageReader.cpp b/Source/platform/image-decoders/bmp/BMPImageReader.cpp
index 55e8190084b1ebdd343c30afae46f2419cfdb18c..5f4d7cfad0798682d50819f9eaa67b8ff1b3625e 100644
--- a/Source/platform/image-decoders/bmp/BMPImageReader.cpp
+++ b/Source/platform/image-decoders/bmp/BMPImageReader.cpp
@@ -138,7 +138,7 @@ bool BMPImageReader::decodeBMP(bool onlySize)
 
     // If the image has an AND mask and there was no alpha data, process the
     // mask.
-    if (m_isInICO && !m_decodingAndMask && !m_buffer->hasAlpha()) {
+    if (m_isInICO && !m_decodingAndMask && !m_buffer->hasAlpha() && !m_seenNonZeroAlphaPixel) {

[Peter Kasting, 2014/11/21 20:05:54]

You shouldn't need to check m_buffer->hasAlpha() anymore.

I wonder if you need to check m_bitMasks[3], though:

  ... && (!m_bitMasks[3] || !m_seenNonZeroAlphaPixel)

If m_bitMasks[3] is zero, the image has explicitly said it has no alpha channel.
 In this case, m_seenNonZeroAlphaPixel is always going to be true, since we
pretend the alpha value is always 255.  But I think you want to use the AND mask
anyway.  I don't know if Mozilla does this -- it looks to me like they may not
handle BI_BITFIELDS correctly for 32bpp images (but rather assume the image is
always in 8888 form).  But it might be worth creating a test image that is 32bpp
with a zero-width alpha channel and seeing whether e.g. Windows respects the AND
mask.  We could use that in a layout test too.

         // Reset decoding coordinates to start of image.
         m_coord.setX(0);
         m_coord.setY(m_isTopDown ? 0 : (m_parent->size().height() - 1));