Bug 307197 – NavigationEvent#canIntercept is true when navigating to a different port

• Status: RESOLVED
• Resolution: FIXED
• Component: Page Loading

[Dom Christie]

Created attachment 478272 [details]
A file that spins up 2 node servers: one at port 3000 and the other at 3001. NavigationEvent#canIntercept is logged in the browser console

[The spec](https://html.spec.whatwg.org/multipage/nav-history-apis.html#dom-navigateevent-canintercept-dev) states:

> Generally speaking, this will be true whenever the current Document can have its URL rewritten to the destination URL, except for in the case of cross-document "traverse" navigations, where it will always be false.

and [defining when a document have have it's URL rewritten](https://html.spec.whatwg.org/multipage/nav-history-apis.html#can-have-its-url-rewritten):

> A Document document can have its URL rewritten to a URL targetURL if the following algorithm returns true:
> …
> If targetURL and documentURL differ in their scheme, username, password, host, or port components, then return false.

In my tests, when navigating from localhost:3000 to localhost:3001, `navigattionEvent.canIntercept` returns `true`.

[Ahmad Saleem]

Navigation::DispatchResult Navigation::innerDispatchNavigateEvent

has:

bool canIntercept = documentCanHaveURLRewritten(*document, destination->url()) && (!isTraversal || isSameDocument);

Which is coming from here:

static bool documentCanHaveURLRewritten(const Document& document, const URL& targetURL)
{
    const URL& documentURL = document.url();
    Ref documentOrigin = document.securityOrigin();
    auto targetOrigin = SecurityOrigin::create(targetURL);
    bool isSameSite = documentOrigin->isSameSiteAs(targetOrigin);
    bool isSameOrigin = documentOrigin->isSameOriginAs(targetOrigin);

    // For cross-window navigation with document.domain, we need to check same-origin rather than same-site
    // to account for document.domain modifications that make cross-origin windows same-origin-domain
    if (!isSameSite && !isSameOrigin)
        return false;

    if (targetURL.protocolIsInHTTPFamily())
        return true;

    if (targetURL.protocolIsFile() && !isEqualIgnoringQueryAndFragments(documentURL, targetURL))
        return false;

    return equalIgnoringFragmentIdentifier(documentURL, targetURL);
}

^ We don't check this bit here - > If targetURL and documentURL differ in their scheme, username, password, host, or port components, then return false.

So something like this might fix it:

```

    if (documentURL.protocol() != targetURL.protocol()
        || documentURL.user() != targetURL.user()
        || documentURL.password() != targetURL.password()
        || documentURL.host() != targetURL.host()
        || documentURL.port() != targetURL.port())
        return false;

```

I tested above on WPT but WPT does not seems to have coverage.

[Radar WebKit Bug Importer]

<rdar://problem/169845691>

[Ahmad Saleem]

Pull request: https://github.com/WebKit/WebKit/pull/58094

[EWS]

Committed 307316@main (850ce3163e55): <https://commits.webkit.org/307316@main>

Reviewed commits have been landed. Closing PR #58094 and removing active labels.