You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The IDE was reachable six ways. Three of them swapped the shell inside the
running process, so the Fiddle you were working in silently became a different
product — and that is not only jarring, it breaks the assumption the one
deliberate path was built around. openShowcaseInIdeWindow spawns a child
process for a documented reason: the Scintilla registry, its keyWindow attach,
and the config-store writer lease all assume ONE WINDOW PER PROCESS. One entry
point honoured that; the rest went around it.
One rule now: opening a workspace spawns a window, and every command says where
it lands.
- File ▸ Open Folder in IDE… and the palette's Open Folder in IDE (⇧⌘O) spawn
- Open Showcase from URL in IDE — it was "Open Showcase (URL)", differing from
"Open Showcase" only in which product it dropped you into, with nothing in
either name to say so — spawns too
- File ▸ Open Fiddle Folder… (⌘O) still loads into this Fiddle, and says so
The folder reaches the child by env, not by deep link. The deep-link scheme is
a public contract with a parser and tests; "open this local directory" is a
private handoff between a parent window and the child it just spawned.
Also drops a duplicate delivery. main.ts answered the openFolder bridge call
twice — reply callback plus a `folderOpened` broadcast, a fallback from when
the reply was unreliable on some runtimes. Two deliveries were harmless while
both did the same thing; with the callback now spawning, honouring the
broadcast as well would have opened the new window AND converted this one.
The helper sits above openFolderDialog rather than beside its siblings further
down: Lynx evaluates a useCallback's dependency array at declaration, so a
later declaration referenced from an earlier one is a load-time TDZ crash.
0 commit comments