Since 27.9.1, ImageBlob → createObjectURL → <img> misdecodes every documented format. Verified with the attached minimal repro plugin: correct on 26.11.2, broken on 27.9.1 and 27.10.0, same machine (screenshots attached).
Gray (1), GrayscaleAlpha (2), RGB (3): silently scrambled, no exception thrown. The decoder appears to read at a 4-byte stride, so it also reads past the end of the buffer and renders stale process memory (output changes on every redraw). The docs’ own example, a 3-component buffer of [255,0,0] triplets, does not render red.
RGBA (4): channels rotated
the decoder consumes bytes as literal A,R,G,B. Writing the same pixels with alpha first renders the true image (repro row 6). Bytes B,G,R,A (a little-endian 0xAARRGGBB word) do not render correctly (row 7), so it’s a byte-order change, not an endian swap.
The repro is self-contained (no build step, load via UDT), renders one known pattern through each format on both panel and modal-dialog surfaces, and prints expected results per row. Timing lines up with the new UI backend rollout, ImageBlob hands raw buffers to exactly that layer.
Thanks Haller. I was the one who posted it in the Drover thread 24 days ago, but I never got a response. Is that where did you saw it before? Do you know the Jira ticket number or what build the fix is targeted for?
Short version: in the shipping release, ImageBlob decodes none of its documented pixel
formats correctly. The only byte order that renders correctly is one the docs do not
describe: alpha first, A,R,G,B, with the meta still saying RGBA.
The repro is attached to the first post: no build step, loads in UDT, renders one known
pattern through every documented format and prints the expected result per row. Gray,
GrayscaleAlpha and RGB come out scrambled with no exception thrown. The docs’ own example,
a 3-component buffer of [255,0,0] triplets, does not render red.
I reported this in the UXP UI backend thread (11910, post 53) on Aug 15, which is why I
think it is Drover.
We do ship around it, so this is not a request to hurry. What I need is the build number
where the decoder is fixed. The workaround is a version test with no upper bound, so on the
day the fix ships every installed copy starts rendering rotated again with no change from
us, and turning it off early breaks the older builds. A heads up in this thread with the
target build is worth more to me than the fix date.
Sorry for the direct tag. This has had no reply in a month and it is in the release build.
Update: on Windows this is total failure, not a misdecode.
Same repro as the first post. On Windows 27.9.1 and 27.10.0 no documented format renders at
all: the blob and its object URL are created without error, then onload never fires, onerror
never fires, naturalWidth stays 0, and Photoshop reports “Uncaught class
droverbindings::droverbindings_error while executing UXP TaskQueue item”. No byte order or
component count avoids it, and it is identical with Use Graphics Processor off.
The same pattern as a PNG through the same renders perfectly on that machine and build,
so Blob, object URLs and decoding are all fine. It is ImageBlob’s uncompressed path.
