Relative <base> in about:blank documents (tracking)

[annevk]

Tracking test (draft) for a relative <base> href in an about:blank document, and its interaction with cloning.

Per the fallback base URL algorithm, an about:blank document's fallback base URL is its initiator's base URL, and a <base> element resolves its href against the fallback base URL. So a relative <base href="sub/"> should resolve against the inherited base URL — both for the document itself and for clones of it.

Browsers currently resolve it against about:blank instead. Open question: fix the browsers, or special-case about:blank in the specification.

Related existing coverage:

• html/semantics/document-metadata/the-base-element/base_about_blank.html
• html/infrastructure/urls/terminology-0/document-base-url.html

Context: whatwg/dom#454

Draft, kept open to track the resolution of the spec question. Do not merge yet.

[annevk]

Summary of the situation.

Subtest 1 (relative <base> in a loaded about:blank iframe) passes in WebKit, fails in Firefox. Subtest 2 (clone) fails in both; in WebKit the shallow clone is fine but the deep clone re-resolves the cloned <base> to about:blank.

Why: WebKit recomputes an about:blank/about:srcdoc document's inherited base URL live from parentDocument()/opener, which a clone (no frame) loses. HTML instead uses a stored snapshot (about base URL), so an engine implementing that (and copying it on clone) would pass — WebKit's live lookup is the divergence.

whatwg/dom#1492 + whatwg/html#12674 add a base URL override that fixes the shallow clone, but not the deep clone (which re-resolves the <base> against fallback base URL; those PRs don't copy about base URL).

The fork:

• A: accept that a relative <base> in about:blank/about:srcdoc resolves against the document's own URL. Then about base URL and base URL override can merge into one field (double-resolution goes away). Regresses relative-<base> inheritance that works today (WebKit about:blank; srcdoc more broadly); ordinary relative URLs still inherit.
• B: also snapshot-copy about base URL on clone so the cloned <base> re-resolves against the inherited base. Keeps current behavior, but needs engines to store about base URL rather than doing the live lookup.

Draft until we pick A or B. srcdoc counterparts added.

[annevk]

Changing my mind toward A (single field), on minimal state.

• A: drop about base URL; keep one base URL override, set from the initiator on creation and from the source on clone, consulted only in the no-<base> branch. fallback base URL collapses to the document's URL, so a <base> always resolves against the (copied) URL — no drift.
• B: keeps both fields; the extra one only buys a relative <base> in about:blank/about:srcdoc resolving against the inherited base rather than against about:blank/about:srcdoc.

Since relative-<base> inheritance isn't a goal, A wins on state. The consequence to accept: a relative <base> in about:blank/about:srcdoc resolves to the document's own URL; ordinary relative URLs (<a>, <img>, …) still inherit via the no-<base> branch.

Flipped the relative-<base> tests here to A's expectations (resolve to about:blank/about:srcdoc). Keeping this as a separate PR for now.