Context
The operator asked for a visible explanation when Workstation cannot open a popup for multi-window dragging or pop-out features. The agreed outcome is recorded on the existing acquisition ticket. This leaf makes that UI work independently actionable within #15239; #15245 retains its broader acquisition/default-selection scope.
The Problem
The existing tear-out admission path safely continues in-window after a refused open, but the user needs to know why the expected window did not appear and what to do next. Popup permission is a one-time site setup for this workflow. The Colors permission UI concerns window-management, a different permission, so its success cannot certify popup availability.
The Architectural Reality
Design authority: the operator's requested visual popup guidance, recorded above, plus TearOut's existing fail-closed, zero-mutation fallback.
At verified source 87b051d023, src/Main.mjs#windowOpen returns Boolean admission from the returned window handle. Workstation's VesselWorkspace#openTearOutVessel records windowOpen-false and returns null. Use that actual acquisition result, preserving the existing dock choreography. The Colors view/controller is a UI precedent only; do not query window-management as a substitute for popup permission.
The Fix
Show a bounded, readable warning on the Workstation browser-hosted surface when an attempted popup open is refused. Cover both drag tear-out and explicit pop-out through their existing acquisition paths. Suggested copy:
The browser could not open this window. Allow pop-ups for this site to use multi-window dragging and pop-out views.
Explain the browser's site-setting action. Use existing Neo UI/controller/provider and styling primitives. Keep the warning non-modal so the ongoing in-window drag can continue. Deduplicate repeated refusals and clear stale guidance after a later successful open. A refusal is observed; the exact stored browser setting is not read.
Contract Ledger
| Surface |
Authority |
Behavior |
Fallback |
Docs |
Evidence |
| Workstation refused-open feedback |
Existing acquisition result; operator request |
Visible next-step guidance for actual browser-popup refusal |
Keep in-window drag, content and document intact |
Owning controller/view JSDoc |
Refused tear-out and explicit-pop-out browser controls |
| Warning lifetime / host scope |
Current acquisition outcome and existing host identity |
Deduplicate failures, clear after success; browser-setting advice only for browser-hosted opens |
Unknown/other failures keep their honest existing diagnosis |
UI state intent |
Retry-success, repeated-refusal and shell controls |
Decision Record impact: aligned-with ADR0029 admission/fallback; no lifecycle or policy amendment.
Acceptance Criteria
Out of Scope
Startup trial popups, reading or changing browser settings, new permissions/API abstractions, popup placement or park policy, new acquisition machinery, the full portability matrix, and film recording. No dependence on finishing the entire three-OS matrix is introduced for this bounded UI explanation.
Avoided Traps
Do not flash a test window at startup, equate a granted window-management permission with popup permission, claim to know the exact cause from a false return, or change successful drag behavior merely to show guidance.
Related and ownership
#15239 · #15245 · #19533. Prior ordinary-Chrome blocked→site-allow→success receipt.
unowned-rationale: A scoped implementation backlog leaf requested during operator discussion; current Dock owners retain their active repair lanes. Any maintainer may self-select after checking overlapping Workstation edits.
Creation checks
2026-10-10: live latest20 open Engine issues, exact popup-warning search and recent30 all-state A2As found no dedicated warning ticket. Two own assignments (#16151/#15526) do not overlap. MC58a6758e and0a3dbf83 preserve the agreed warning and source evidence; earlier KB/history sweep found broad #15245, not a delivered warning. Existing Workstation/Colors owners only; no new module or Agent OS placement prescribed.
Origin Session ID: b56dbc41-6e95-4210-a2ea-8d1f5f3ffcd0
Retrieval Hint: "Workstation popup refused visual warning Colors window-management distinct"
Context
The operator asked for a visible explanation when Workstation cannot open a popup for multi-window dragging or pop-out features. The agreed outcome is recorded on the existing acquisition ticket. This leaf makes that UI work independently actionable within #15239; #15245 retains its broader acquisition/default-selection scope.
The Problem
The existing tear-out admission path safely continues in-window after a refused open, but the user needs to know why the expected window did not appear and what to do next. Popup permission is a one-time site setup for this workflow. The Colors permission UI concerns
window-management, a different permission, so its success cannot certify popup availability.The Architectural Reality
Design authority: the operator's requested visual popup guidance, recorded above, plus
TearOut's existing fail-closed, zero-mutation fallback.At verified source
87b051d023,src/Main.mjs#windowOpenreturns Boolean admission from the returned window handle. Workstation'sVesselWorkspace#openTearOutVesselrecordswindowOpen-falseand returns null. Use that actual acquisition result, preserving the existing dock choreography. The Colors view/controller is a UI precedent only; do not query window-management as a substitute for popup permission.The Fix
Show a bounded, readable warning on the Workstation browser-hosted surface when an attempted popup open is refused. Cover both drag tear-out and explicit pop-out through their existing acquisition paths. Suggested copy:
Explain the browser's site-setting action. Use existing Neo UI/controller/provider and styling primitives. Keep the warning non-modal so the ongoing in-window drag can continue. Deduplicate repeated refusals and clear stale guidance after a later successful open. A refusal is observed; the exact stored browser setting is not read.
Contract Ledger
Decision Record impact: aligned-with ADR0029 admission/fallback; no lifecycle or policy amendment.
Acceptance Criteria
Out of Scope
Startup trial popups, reading or changing browser settings, new permissions/API abstractions, popup placement or park policy, new acquisition machinery, the full portability matrix, and film recording. No dependence on finishing the entire three-OS matrix is introduced for this bounded UI explanation.
Avoided Traps
Do not flash a test window at startup, equate a granted window-management permission with popup permission, claim to know the exact cause from a false return, or change successful drag behavior merely to show guidance.
Related and ownership
#15239 · #15245 · #19533. Prior ordinary-Chrome blocked→site-allow→success receipt. unowned-rationale: A scoped implementation backlog leaf requested during operator discussion; current Dock owners retain their active repair lanes. Any maintainer may self-select after checking overlapping Workstation edits.
Creation checks
2026-10-10: live latest20 open Engine issues, exact popup-warning search and recent30 all-state A2As found no dedicated warning ticket. Two own assignments (#16151/#15526) do not overlap. MC58a6758e and0a3dbf83 preserve the agreed warning and source evidence; earlier KB/history sweep found broad #15245, not a delivered warning. Existing Workstation/Colors owners only; no new module or Agent OS placement prescribed.
Origin Session ID: b56dbc41-6e95-4210-a2ea-8d1f5f3ffcd0 Retrieval Hint: "Workstation popup refused visual warning Colors window-management distinct"