Skip to content

Record that the vanishing Layer 1 is Photoshop's own Place - #176

Merged
MehranMarxian merged 1 commit into
mainfrom
docs/layer1-is-photoshop-place
Nov 5, 2026
Merged

MehranMarxian merged 1 commit into
mainfrom
docs/layer1-is-photoshop-place

Conversation

@MehranMarxian

@MehranMarxian MehranMarxian commented Nov 5, 2026 •

Copy link
Copy Markdown
Owner

Records the decision on finding (3) from the 2026-11-05 G4 smoke run: "Importing the first result into a new document still removes its empty Layer 1." Docs only, no code change.

What changed and why

The finding isn't caused by OpenLayer. It's Photoshop's own Place, and Mehran decided to keep it as is.

Evidence

  • Nothing in OpenLayer deletes the layer. importGeneratedImageAsLayer (src/photoshop/photoshopAdapter.ts) only places, renames and positions it. deleteLayerById is used only for temporary mask layers and for rolling back a failed import.
  • Nothing marks it as deliberate. No comment and no commit says so. It was first recorded in the 2026-10-15 run with the cause unknown, then listed under v0.41.0's known limitations.
  • The control run (Photoshop 2025, Windows 11, 2026-11-05). I made a new 1024 × 1024, 72 ppi, transparent document, then used File › Place Embedded with a small PNG, without OpenLayer. The empty Layer 1 disappeared. History showed only New then Place Embedded Smart Object, and the placed image was the only layer.
  • The empty-only check. I undid that, filled Layer 1 (Alt+Backspace) and placed the same PNG again. This time Layer 1 stayed, below the placed layer. So Photoshop replaces the starting layer only while it's empty.

Edits

  • docs/uxp-smoke-checklist.md step 1.2 now says the empty Layer 1 disappearing on the first import into a new transparent document is expected, so future runs don't report it.
  • docs/beta-gate.md G4 status records the cause and the keep decision.
  • CHANGELOG.md v0.41.0 known limitations: the line keeps its wording and adds that it turned out to be Photoshop's own behaviour.

The Results rows in the smoke checklist are a historical record, so I left them as they were.

What was verified

> npm run typecheck
> tsc --noEmit
(no errors)

> npm run lint
> eslint .
(no errors)

> npm test
 Test Files  142 passed (142)
      Tests  1402 passed (1402)

> npm run build
✓ built in 1.07s
Copied UXP assets to dist.

The Photoshop control run is described above. The test document was closed without saving.

What could NOT be verified

  • Photoshop 2024 and macOS. I expect the same behaviour, since it's the host's own Place, but I haven't run it there.
  • Whether a single Ctrl+Z after an OpenLayer import brings Layer 1 back. I only checked undo on Photoshop's own Place, so the docs don't claim it.

Open question

The published v0.41.0 release notes on GitHub still list this as an OpenLayer limitation. I haven't touched the release. If you want it corrected there too, say so and I'll edit the release body.

What Mehran should check in Photoshop

Optional, since the behaviour isn't changing. To see it yourself:

  1. File › New, 1024 × 1024, Background Contents Transparent › Create. The Layers panel shows Layer 1.
  2. File › Place Embedded..., pick any PNG, press Enter. See: Layer 1 is gone and only the placed layer remains.
  3. Close it with No to saving.

Smoke checklist blocks to re-check (docs/uxp-smoke-checklist.md)

  • None needed for this docs-only change. Step 1.2's new note gets read on the next full G4 run.

🤖 Generated with Claude Code

The 2026-10-15 and 2026-11-05 smoke runs both reported that importing the
first result into a new document removes its empty Layer 1, with the
cause unknown. Nothing in OpenLayer deletes it: the import only places,
renames and positions the layer.

A control run in Photoshop 2025 settled it. File > Place Embedded of a
PNG into a new transparent document, with no plugin involved, removed the
empty Layer 1 the same way (History: New, then Place Embedded Smart
Object). With Layer 1 filled first, the same place kept it.

Mehran decided to keep the behaviour. Smoke step 1.2 now says it is
expected so future runs stop reporting it, the beta gate records the
decision under G4, and the v0.41.0 known-limitations line names the real
cause.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@MehranMarxian
MehranMarxian merged commit d22ea7b into main Nov 5, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant