Qualify VS Code remote file and folder picker interaction #247

Activity

1. wieslawsoltes

   added

   vscode-oss/plannedPlanned for the AppScene/WebScene VS Code OSS integrationPlanned for the AppScene/WebScene VS Code OSS integration

   on Sep 17, 2026
2. wieslawsoltes

   added a sub-issue on Sep 17, 2026

   • Expose HTMLAnchorElement branding required by VS Code file interactions #249
3. wieslawsoltes commented on Sep 17, 2026

   

   wieslawsoltes

   on Sep 17, 2026

   CollaboratorAuthor

   More actions

   First reproduced prerequisite is fixed and merged.

   • Packaged reproduction emitted ReferenceError: HTMLAnchorElement is not defined from unchanged VS Code's realm-aware anchor check.
   • Child Expose HTMLAnchorElement branding required by VS Code file interactions #249 / PR Expose HTMLAnchorElement in native DOM realms #250 added generated HTMLAnchorElement branding for top-level and iframe realms and merged at 6566cf3b.
   • Direct evidence: native and Chrome each pass 1/1 document and 5/5 assertions; focused native branding plus the existing anchor/download handoff regression pass; 4,096 repeated wrapper checks retain identity.
   • The portable V8 and macOS NativeAOT checks passed before merge; remaining duplicate jobs were canceled under the focused fast-merge policy.

   The #247 consumer trace now continues from merged WebScene 6566cf3b to locate the next command/dialog/enumeration/navigation boundary. This completion does not yet prove that Open File or Open Folder works.
4. wieslawsoltes

   added a parent issue on Sep 17, 2026

   • [Epic] Complete remaining Code OSS native release acceptance #227
5. wieslawsoltes commented on Sep 17, 2026

   

   wieslawsoltes

   on Sep 17, 2026

   CollaboratorAuthor

   More actions

   Qualification checkpoint after #250:

   • The unchanged VS Code OSS File: Open Folder... command now reaches and renders the remote SimpleFileDialog; the earlier HTMLAnchorElement failure is gone.
   • The picker enumerated the product-neutral fixture and accepted /private/tmp/webscene-247-fixture/beta/ through the real dialog.
   • Measured first visibility was 901.25 ms, within the 2 s bound; the observer saw at most 122 dialog DOM nodes and 2 rendered rows in the retained sample.
   • The AppScene window became unavailable immediately after submission. The polling diagnostic retained the active folder call but missed the synchronous BrowserHostService.openWindow frame, so it did not retain the selected vscode-remote URI/options.

   The local, query-gated consumer observer now emits the handoff JSON synchronously before invoking the real host method; its focused tests pass 26/26. No VS Code source was changed and no WebScene contract change is justified from this run. Keeping #247 open until one final run retains the exact selected URI/openWindow request. AppScene #124 is not yet claimed as the next blocker because this boundary is still unproven.
6. wieslawsoltes commented on Sep 17, 2026

   

   wieslawsoltes

   on Sep 17, 2026

   CollaboratorAuthor

   More actions

   Follow-up capture with the navigation-safe handoff observer was inconclusive and does not change the qualification state.

   • Rebuilt the changed workbench overlay with exact build/runtime Node 24.18.1; overlay SHA-256 035b784f74f31d34bfd05ba0b96249a2ef5424e1577fee4a253d51b0d2e443dc.
   • The packaged app reached the unchanged Welcome surface with the observer installed.
   • The attempted Command Palette text was intercepted by the focused Chat/Copilot surface and raised a Copilot sign-in modal. Subsequent automated pointer/key activation was routed to another frontmost desktop application rather than the AppScene document.
   • No SCENETECH_REMOTE_PICKER_HANDOFF record was emitted. This run therefore proves neither success nor failure of the selected vscode-remote URI boundary.

   The run stopped at that exact focus/input-routing boundary without further retries; all AppScene processes were closed. Keep #247 open. The local-only diagnostic commits remain d813f2b and 92a9716; focused observer/native tests pass 26/26 and no VS Code source was changed.
7. wieslawsoltes commented on Sep 17, 2026

   

   wieslawsoltes

   on Sep 17, 2026

   CollaboratorAuthor

   More actions

   Hierarchy audit: #247 remains the sole P0 owner of the remote command → SimpleFileDialog → exact selected URI/BrowserHostService.openWindow boundary. AppScene#124 starts at the resulting target URL/navigation request; #252 starts at new-document workspace/provider reconstruction; #269 starts at file-model open/edit/save/recovery.

   The final qualifying matrix must include Open File, Open Folder, Add Folder, Open Workspace, and remote Save As; pointer and keyboard; accept/cancel/error; hidden/Unicode/symlink/large-directory entries; byte-exact URI scheme/authority/path/query serialization; correct force-new/reuse/add-mode options; focus restoration; no retained rows/requests; and cold/warm latency/DOM/scene bounds. The 24.18.1 follow-up capture was inconclusive because Chat/Copilot focus intercepted the command and desktop input left the AppScene document, so it supplies no handoff claim and no new engine issue.
8. wieslawsoltes commented on Sep 17, 2026

   

   wieslawsoltes

   on Sep 17, 2026

   CollaboratorAuthor

   More actions

   Wave 0 qualification is complete with the exact unchanged VS Code service handoff retained.

   The query-gated diagnostic invoked the real workbench.action.files.openFolder action directly, removing the earlier Command Palette/Chat focus ambiguity while leaving picker selection and product behavior unchanged. The packaged AppScene/WebScene run selected the product-neutral fixture folder and synchronously observed BrowserHostService.openWindow:

   {
     "callSequence": 1,
     "elapsedMs": 66704.56654191017,
     "openables": [{
       "kind": "folder",
       "scheme": "vscode-remote",
       "authority": "127.0.0.1:64170",
       "path": "/private/tmp/webscene-247-fixture/beta",
       "value": "vscode-remote://127.0.0.1:64170/private/tmp/webscene-247-fixture/beta"
     }],
     "options": {
       "forceNewWindow": false,
       "forceReuseWindow": false,
       "addMode": false
     }
   }

   Retained observer state records calls[0].outcome = "handoff", driver status resolved, 4 visible fixture rows, maximum 17 rendered rows, 512 dialog DOM nodes, and sampling p95 2.11 ms. This cold-start diagnostic invoked Open Folder as soon as the workbench DOM appeared; its 3.55 s dialog visibility sample is therefore a startup-overlap sample, not a regression conclusion. The prior ready-workbench capture measured 901.25 ms within the 2 s picker bound. No generic WebScene/AppScene defect is identified by this evidence.

   Build/validation:

   • pinned unchanged VS Code: 645f29cc3176500b4b5762ba887cf2a7f0ffdf2c
   • merged WebScene prerequisite: 6566cf3b
   • exact Node: 24.18.1
   • query-gated local diagnostic commit: d69ead7
   • workbench SHA-256: 16915e1e611eca6bdf323587030048f4902d0ba501efc22691525214bca98179
   • focused observer/native tests: 26/26 passed
   • all AppScene/server processes closed after the bounded run

   The selected remote URI and same-window option set are correct. AppScene#124 now owns target-URL/navigation/lifecycle qualification; WebScene#252 starts after navigation at new-document workspace/provider reconstruction. No #124/#252 implementation was started here.
9. wieslawsoltes

   closed this as completedon Sep 17, 2026