Cross-repository epic: SceneTech/AppScene#122
Parent file/folder qualification: #247
Reproduction
On AppScene a20cf890 and WebScene 7cd66b3e, launch the packaged unchanged VS Code OSS 1.137 workbench, open the command palette, and exercise the file/folder interaction path. The native runtime repeatedly reports:
Uncaught ReferenceError: HTMLAnchorElement is not defined
.../out/vs/code/browser/workbench/workbench.js:439:11096
The failure was captured in /tmp/codeoss-open-folder-repro/run3.err with the real packaged app. WebScene's generated native DOM bindings expose HTMLElement and several specialized element constructors, but they do not expose HTMLAnchorElement; <a> nodes are therefore wrapped as plain HTMLElement instances. VS Code's unchanged isHTMLAnchorElement() helper directly evaluates both the realm global and getWindow(node).HTMLAnchorElement, so the missing constructor throws before the flow can continue.
Proposed implementation
- Add
HTMLAnchorElement to the explicit WebIDL-to-V8 exposure manifest and regenerate the committed bindings.
- Wrap HTML
<a> nodes with that specialized template while preserving stable wrapper identity and the existing HTMLElement inheritance chain.
- Install the constructor in every top-level and iframe realm with browser-shaped prototype placement and illegal direct construction.
- Keep existing bounded
href, hash, and download behavior; do not broaden URL parsing claims in this change.
- Add a product-neutral native/WPT contract covering global availability,
<a> branding, non-anchor rejection, iframe realm branding, wrapper identity, and VS Code's two-realm instanceof pattern.
Acceptance and gates
Performance bound
Constructor selection remains a constant-time tag comparison during first wrapper creation. Repeated wrapper access must remain identity-stable and allocation-free; include it in the existing DOM binding benchmark or a focused bounded check.
Cross-repository epic: SceneTech/AppScene#122
Parent file/folder qualification: #247
Reproduction
On AppScene
a20cf890and WebScene7cd66b3e, launch the packaged unchanged VS Code OSS 1.137 workbench, open the command palette, and exercise the file/folder interaction path. The native runtime repeatedly reports:The failure was captured in
/tmp/codeoss-open-folder-repro/run3.errwith the real packaged app. WebScene's generated native DOM bindings exposeHTMLElementand several specialized element constructors, but they do not exposeHTMLAnchorElement;<a>nodes are therefore wrapped as plainHTMLElementinstances. VS Code's unchangedisHTMLAnchorElement()helper directly evaluates both the realm global andgetWindow(node).HTMLAnchorElement, so the missing constructor throws before the flow can continue.Proposed implementation
HTMLAnchorElementto the explicit WebIDL-to-V8 exposure manifest and regenerate the committed bindings.<a>nodes with that specialized template while preserving stable wrapper identity and the existingHTMLElementinheritance chain.href,hash, anddownloadbehavior; do not broaden URL parsing claims in this change.<a>branding, non-anchor rejection, iframe realm branding, wrapper identity, and VS Code's two-realminstanceofpattern.Acceptance and gates
typeof HTMLAnchorElement === 'function'in top-level and iframe realms.document.createElement('a') instanceof HTMLAnchorElementandinstanceof HTMLElement; non-anchor elements fail the anchor brand.href/hash/downloadtests remain green.isHTMLAnchorElement()completes without exception.Performance bound
Constructor selection remains a constant-time tag comparison during first wrapper creation. Repeated wrapper access must remain identity-stable and allocation-free; include it in the existing DOM binding benchmark or a focused bounded check.