Fix black PNG exports from usage share cards#2292
Conversation
|
Codex review: needs maintainer review before merge. Reviewed July 18, 2026, 5:18 PM ET / 21:18 UTC. Summary Reproducibility: no. independent current-main live reproduction was run in this read-only review, but the reported failure has a concrete base-path explanation: the old renderer captured an offscreen hosting view and only tested the PNG signature; the branch exercises that renderer path with sampled visible-pixel coverage. Review metrics: 2 noteworthy metrics.
Root-cause cluster Members:
Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything. Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Rank-up moves:
Risk before merge
Maintainer options:
Next step before merge
Security Review detailsBest possible solution: Merge the stable exact head after both macOS shards pass, retaining the RGBA AppKit rendering path and sampled-pixel regression test for the existing 1200×630 export contract. Do we have a high-confidence way to reproduce the issue? No independent current-main live reproduction was run in this read-only review, but the reported failure has a concrete base-path explanation: the old renderer captured an offscreen hosting view and only tested the PNG signature; the branch exercises that renderer path with sampled visible-pixel coverage. Is this the best way to solve the issue? Yes. Replacing the brittle offscreen capture path with explicit bitmap-context drawing while retaining the existing payload and 1200×630 contract is a narrow, maintainable regression fix. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against d2a3da910477. Label changesLabel justifications:
Evidence reviewedWhat I checked:
Likely related people:
What the crustacean ranks mean
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics. How this review workflow works
Review history (6 earlier review cycles)
|
|
@clawsweeper re-review |
|
🦞🧹 I asked ClawSweeper to review this item again. Re-review progress:
|
|
CI note: the exact-head Linux x64 failure is unrelated to this macOS renderer diff. The two parameterized |
|
The unrelated Linux x64 flake is now isolated in test-only PR #2311 (fixes #2309). Its focused |
|
Thanks for retrying the flaky Linux shard. I verified |
|
@clawsweeper re-review |
|
🦞🧹 I asked ClawSweeper to review this item again. Re-review progress:
|
|
Merged after exact-head verification. Verification:
Merge SHA: |
Summary
ImageRendererinstead of an offscreenNSHostingView.cacheDisplayFixes #2286.
Part of #2291.
Production evidence
The installed 0.44.0 (build 106) app returned a structurally valid 1200×630 PNG from Copy Image, but every pixel was black:
The final renderer tree (
ddd39620, unchanged by tree-identical CI retry headd4e836fb) rendered the same synthetic payload throughShareStatsRenderer.pngData(for:)as visible, non-uniform output:The screenshot uses synthetic fixture data only. It was freshly generated from the final renderer path after the maintainer's no-Metal revision.
Verification
swift test --filter ShareStatsTests— 12 tests passed on the unchanged renderer treefile/sips— RGBA PNG, exactly 1200×630make check— passed, including SwiftFormat and SwiftLintmake test— 715/715 selections passed across 60/60 groups, with zero retries and zero timeoutsCI evidence
d4e836fbis an empty, tree-identical retry commit because contributor permissions cannot rerun a failed GitHub job directly.