1767001 - history.pushState produces non-DOM errors on about: pages, and doesn't work to go from `about:foo` to `about:foo#hash` despite the spec claiming that should be allowed

Status: NEW

(Core :: DOM: Navigation, defect)

Description

[:Gijs (he/him)]

Spec says:

A Document document can have its URL rewritten to a URL targetURL if the following algorithm returns true:

1. Let documentURL be document's URL.
2. If targetURL and documentURL differ in their scheme, username, password, host, or port components, then return false.
3. If targetURL's scheme is an HTTP(S) scheme, then return true. (Differences in path, query, and fragment are allowed for http: and https: URLs.)
4. If targetURL's scheme is "file", and targetURL and documentURL differ in their path component, then return false. (Differences in query and fragment are allowed for file: URLs.)
5. If targetURL and documentURL differ in their path component or query components, then return false. (Only differences in fragment are allowed for other types of URLs.)
6. Return true.

It also explicitly lists push/replaceState navigation from about:blank to about:blank#hash as allowed, but this doesn't work in practice, producing:

Exception { name: "NS_ERROR_FAILURE", message: "", result: 2147500037, filename: "debugger eval code", lineNumber: 1, columnNumber: 0, data: null, stack: "@debugger eval code:1:9\n" }

This is also against the spec, which says (step 2 of the shared history push/replaceState steps) that there should be a SecurityError DOMException.

AFAICT there aren't (failing) web platform tests for this right now.

Comment 1

[Henri Sivonen (:hsivonen)]

smaug, do you happen to know what's wrong here?

Comment 2

[:Gijs (he/him)]

(In reply to Henri Sivonen (:hsivonen) from comment #1)

smaug, do you happen to know what's wrong here?

FWIW, I analyzed a bit in bug 1766143 comment 2. TL;DR: we enforce here that we can get a userpass from the URL - but blob/about/data URLs aren't nsStandardURLs so attempting to fetch userpass info fails. There might then be additional issues with CheckSameOriginURI for these URLs - the spec as quoted doesn't actually check origins but has a hand-rolled almost-but-not-quite equivalent check.

It also appears this is a dupe of or closely related to bug 1729961.

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

(I don't know why this is being tracked. )