Specify browser UI-initiated navigations better

[domenic]

In particular, they have a null sourceDocument. We need to handle that in various places in the specification.

Closes #9133.

In addition to @domfarolino and @noamr, review from @ADKaster or other Ladybird folks who might have run into this would be much appreciated.

• At least two implementers are interested (and none opposed):
  • This matches all implementations, as far as I can tell.
• Tests are written and can be reviewed and commented upon at:
  • This isn't testable in WPT: Testing browser-initiated navigation. web-platform-tests/wpt#16019
• Implementation bugs are filed:
  • Chromium: N/A
  • Gecko: N/A
  • WebKit: N/A
  • Deno (only for timers, structured clone, base64 utils, channel messaging, module resolution, web workers, and web storage): N/A
  • Node.js (only for timers, structured clone, base64 utils, channel messaging, and module resolution): N/A
• Corresponding HTML AAM & ARIA in HTML issues & PRs: N/A
• MDN issue is filed: N/A
• The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)

---

/browsing-the-web.html ( diff )
/infrastructure.html ( diff )

[ADKaster]

or other Ladybird folks who might have run into this would be much appreciated.

cc @trflynn89 @shannonbooth :)

[annevk]

Looks good. This puts some pressure on Fetch getting its null client act together.

[domenic]

I will hold off on merging this until we have agreement that whatwg/fetch#1820 is the right way to fix the request's window. (For example, we might instead prefer callers to set it.)

[ADKaster]

Implementation musings:

Implementing this in LadybirdBrowser/ladybird#4515 caused one of my tests for the state of window.navigation.canGoBack after a BrowserUI initiated navigation to fail -- the current entry index got reset to 0. I think that's... correct? Because our test runner does this:

load(about:blank)
load(test file url)
<wait for test to complete>
load(about:blank)
load(test file url)
<wait for test to complete>

Though navigating to about:blank causing all previous state to go kaput seems odd, it's not like anyone who isn't trying to stress test the browser would do that during normal operation, right? ...

[domenic]

I think that's correct too. In theory, web platform tests are meant to be run as if you've started the browser from scratch for every test. If you want to test a series of documents, you need to use iframes or popup windows.

In practice, most browser/test runner combos do not do this. (This leads to annoying changes like web-platform-tests/wpt@0a5ef44 ; see also web-platform-tests/wpt#33590.) But the closer we can get to that ideal, the better.

[domenic]

Marking "do not merge yet" until we get whatwg/fetch#1821 landed and revise this to use it.

[domenic]

I've updated this to use the latest from Fetch, hooray!

If someone wants to give this an extra review, I'd appreciate it, but if not I'll plan on landing this next Monday.

[domenic]

(Thanks for the review! After writing up something along the lines of what you're suggesting, I think it's a good bit better, so I appreciate the push.)

[noamr]

(Thanks for the review! After writing up something along the lines of what you're suggesting, I think it's a good bit better, so I appreciate the push.)

That bit is much more readable, thanks!