browsingContext.navigate expects to read the navigation id for the browsingContext just before resolving, but in case of a wait=none navigation, we might not have had time for the content process listener to reach the parent process.

In those cases the navigation id returned from browsingContext.navigate will be the previous one stored for this navigation.

We should create the id directly in browsingContext.navigate since we know we should expect a navigation, and also this is in-line with the BiDi spec for await a navigation which says that the navigation UUID should be created here and used by HTML's navigate.

We can basically do the same as what the network module does for beforeRequestSent: https://searchfox.org/mozilla-central/rev/c51359e1e6beeb6cee5eafe67272c9be16fcf5c1/remote/webdriver-bidi/modules/root/network.sys.mjs#472-480

Looking at Bug 1769514, we need to be careful not to simply trigger a navigation-started whenever browsingContext.navigate is called.
navigate could very well just result in a fragment navigation, and in that case even if we want a navigation id, we don't want navigation-started / stopped.

Which means we should only create/prepare the id, but not force the creation of events. Whereas it's safe to do from the network module, because a navigation request means we have a navigation-started event.

Depends on D192110

I'll check if this is landable.

I've requested lando to land the revisions.

https://hg.mozilla.org/mozilla-central/rev/4180e81f2e99
https://hg.mozilla.org/mozilla-central/rev/e6241b851988