mirror of
https://github.com/storytold/wordcraft.git
synced 2026-10-27 03:47:09 -06:00
VoiceLessQ
5929374704
On Windows the paste path asked arboard (3.6.1) for decoded pixels. arboard decodes the registered "PNG" format and CF_DIBV5 with no image limits, so a clipboard item of a few dozen bytes whose header declares 100,000 x 100,000 pixels made the decoder allocate tens of GB. The allocation failure aborted the app outside Session::run's guard, before paste_picture's size checks ever saw the picture. On Windows the app now reads the clipboard itself (clipboard-win, the raw read capped at 200 MB): - "PNG" goes to Insert Picture as encoded bytes, once its header shows a size a paste takes (16,000 a side, 50 M pixels). - Otherwise CF_DIBV5 or CF_DIB is probed through wordcraft_geom::picture::probe_dib, checked the same way, then decoded within the decode budget into pixels. probe_dib reads a DIB in the layout the image crate expects: a 32-bit BI_RGB DIB with an alpha mask becomes bit fields, so its alpha is kept as arboard did. A V4 or V5 bit-field DIB without the copy of its colour masks after the header (arboard writes one) gets that copy, because the decoder skips 12 bytes there and would otherwise read into the pixels. Linux keeps using arboard, which decodes the clipboard's PNG within the image crate's default 512 MB limit. macOS keeps it too: arboard decodes the pasteboard's TIFF there, which can still reach the JPEG strip decoder of #3645; that path is untouched here because it can't be built or run on this machine. cargo check and clippy for x86_64-pc-windows-gnu pass on the Windows-only code; it hasn't been run on Windows.