Skip to content

feat(html): implement HTMLIFrameElement contentWindow/contentDocument - #278

Open
Sonic-Y3k wants to merge 1 commit into
gost-dom:mainfrom
Sonic-Y3k:feat/iframe
Open

feat(html): implement HTMLIFrameElement contentWindow/contentDocument#278
Sonic-Y3k wants to merge 1 commit into
gost-dom:mainfrom
Sonic-Y3k:feat/iframe

Conversation

@Sonic-Y3k

@Sonic-Y3k Sonic-Y3k commented Jun 27, 2026

Copy link
Copy Markdown

HTMLIFrameElement: contentWindow / contentDocument

Adds an HTMLIFrameElement exposing the nested browsing context via contentWindow
and contentDocument, and creates iframe elements from
document.createElement("iframe").

Compliance / known limitation

A faithful implementation would give each iframe its own same-origin JavaScript
realm (distinct native built-ins, mutually accessible with the parent). gost-dom
binds one realm per script context, and the v8go build does not expose
security-token control, so a separate child context's globals are not
cross-realm accessible. Until that lands, the nested context resolves to the
owning window's realm: every native built-in on contentWindow (Function, String,
eval, ...) stays accessible and genuine; only object identity differs from a
real same-origin iframe.

Split out of #274. The script-engine binding lives in its own file and the test
runs in the shared suite, so both the V8 and Sobek engines are covered.


AI disclosure: This change was developed with the help of an AI coding assistant. I've reviewed and tested it myself; it follows the existing conventions and the full test suite (main module, v8engine, sobekengine) passes locally.

@coderabbitai

coderabbitai Bot commented Jun 27, 2026

Copy link
Copy Markdown
Contributor

Warning

Review limit reached

@Sonic-Y3k, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 23 minutes and 21 seconds. Learn how PR review limits work.

Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file).

⌛ How to resolve this issue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits.

🚦 How do rate limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: b3de96ba-e16b-4cba-9f0e-70fb9bd8a1d2

📥 Commits

Reviewing files that changed from the base of the PR and between 98adcf9 and c8854d1.

📒 Files selected for processing (6)
  • html/html_document.go
  • html/html_iframe_element.go
  • scripting/internal/html/html_iframe_element.go
  • scripting/internal/html/initializer.go
  • scripting/internal/scripttests/iframe_suite.go
  • scripting/internal/scripttests/suites.go

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

Add an HTMLIFrameElement that exposes the nested browsing context via the
contentWindow and contentDocument accessors, and create iframe elements from
document.createElement("iframe").

gost-dom binds one realm per script context and the v8go build does not expose
security-token control, so the nested context currently resolves to the owning
window's realm rather than a separate child realm: every native built-in on
contentWindow stays accessible and genuine, only object identity differs from a
real same-origin iframe.

The script-engine binding lives in its own file and the test runs in the shared
suite, so both the V8 and Sobek engines are covered.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant