[UXP] Color parameter writes lose the blue channel — still reproducible in 26.3 (regression window 26.0.2 → 26.3, no fix)

Environment: Premiere Pro 26.3 (June 2026 release) and 26.0.2 / Windows 11 / UXP panel (manifest v5)

Summary

Writing any Color value to an effect parameter from a UXP panel corrupts the blue component. We first confirmed this on 26.0.2 across every available write path (static createSetValueAction, keyframe batch via createSetTimeVaryingAction + createAddKeyframeAction, per-keyframe transactions, and packed 64-bit numeric writes). After updating to 26.3 we re-ran a clean minimal test: the bug is unchanged.

Minimal repro (clean 3-keyframe test, 26.3)

1. Apply Drop Shadow to any clip (exactly one instance).
2. From UXP, on "Shadow Color", write three keyframes inside executeTransaction:
   • t+0s → pure red (1, 0, 0, 1)
   • t+1s → pure green (0, 1, 0, 1)
   • t+2s → pure blue (0, 0, 1, 1) (Values built by reusing the host Color object from getStartValue() and assigning components; keyframes via param.createKeyframe() → createAddKeyframeAction.)
3. Check the three keyframes in Effect Controls with the color picker.

Expected: FF0000 / 00FF00 / 0000FF Actual (26.3, verified by eye/picker): FF0000 / 00FF00 / 000000 — red and green land exactly; pure blue renders as black. Any color with a blue component is shifted accordingly (white becomes yellow — matches other developers' forum reports about new ppro.Color(1,1,1,1)).

The readback trap (important for triage)

Readback APIs (getStartValue, getKeyframePtr → 64-bit packed value) return the intended value, not the effective one. In our 26.3 test the packed keyframe values decode to exactly red/green/blue while the screen shows red/green/black. So the corruption happens downstream of the parameter store, is invisible to the API, and cannot be caught by write-verify logic — only visually.

Impact

Color-bearing effects cannot be automated from UXP at all. We ship a workaround that clones whole components between clips ("donor" carriers) just to move colors natively — it works, but it costs a sequence-import pipeline, project-generation bookkeeping, and cache logic that a working Color write would make unnecessary.

Ask

• Fix the blue-channel corruption in the Color write path (all write paths are affected identically, which suggests a single shared conversion step — possibly a 3-channel/BGR conversion or a float→packed step dropping the last channel).
• Until then, please document the limitation, and make readback return effective values so panels can at least detect it.