Skip to content

Expose HTMLAnchorElement branding required by VS Code file interactions #249

Description

@wieslawsoltes

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

  • typeof HTMLAnchorElement === 'function' in top-level and iframe realms.
  • document.createElement('a') instanceof HTMLAnchorElement and instanceof HTMLElement; non-anchor elements fail the anchor brand.
  • Existing anchor href/hash/download tests remain green.
  • A reduced reproduction of VS Code's isHTMLAnchorElement() completes without exception.
  • Direct native V8 runtime tests and binding-generator check pass.
  • Packaged VS Code file/folder qualification proceeds beyond this exception; remaining failures stay in Qualify VS Code remote file and folder picker interaction #247.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingvscode-oss/plannedPlanned for the AppScene/WebScene VS Code OSS integration

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions