diff options
author | Andrew Osmond <aosmond@mozilla.com> | 2019-02-16 20:21:13 +0100 |
---|---|---|
committer | wolfbeast <mcwerewolf@wolfbeast.com> | 2019-02-16 20:21:13 +0100 |
commit | c66d87e6c00b6cbde3336a42aa9964f076dc9b2c (patch) | |
tree | b31311d2a7eedbd476714ca918ddd33cb94e4797 /moz.build | |
parent | 529067c0a2073e26a54441f9994ec814fac76938 (diff) | |
download | UXP-c66d87e6c00b6cbde3336a42aa9964f076dc9b2c.tar UXP-c66d87e6c00b6cbde3336a42aa9964f076dc9b2c.tar.gz UXP-c66d87e6c00b6cbde3336a42aa9964f076dc9b2c.tar.lz UXP-c66d87e6c00b6cbde3336a42aa9964f076dc9b2c.tar.xz UXP-c66d87e6c00b6cbde3336a42aa9964f076dc9b2c.zip |
BMPs from the clipboard may include extra padding.
In the original Windows clipboard BMP decoder implementation in
nsImageFromClipboard::ConvertColorBitMap, if the bitmap used bitfields
compression, it always adjusted the offset to the RGB data by 12 bytes.
It did this even for newer BMP header formats which explicitly include
space for the bitfields in their header sizes. This patch updates our
BMP decoder to do the same for clipboard BMPs, since we have observed
pasted BMPs using bitfield compression appearing incorrectly. To the
user this appears as if we read a color mask; completely red, blue,
green pixels at the start of the last row, causing all of the other rows
to start with the last three pixels of the previous row.
Diffstat (limited to 'moz.build')
0 files changed, 0 insertions, 0 deletions