Currently when a navigation turns into a download, Firefox doesn't send any events for that navigation after browsingContext.navigationStarted. I think the navigation should be cancelled, Chrome currently uses the browsingContext.navigationFailed event (although I'm not sure that's the right one, I also couldn't find anything in the spec for this case, perhaps this is still missing).

Thanks for filing, I think in this case we should emit downloadWillBegin with the same navigation id.
I don't think emitting navigationFailed is the right thing to do spec wise.

WebDriver BiDi download started is invoked at https://html.spec.whatwg.org/#populating-a-session-history-entry:webdriver-bidi-download-started:~:text=Invoke%20WebDriver%20BiDi%20download%20started%20with%20navigable , whereas navigation failed is handled in the previous branch.

At the moment the DownloadListener is responsible for generating navigation ids, but I think we should just delegate that to the NavigationManager?

Oh I remember why I didn't want to create new navigations for downloads. In case of a download attribute, we don't get a navigation started event, and until we monitor the end of the download I didn't want to have navigations lingering in an unfinished state.

Nevertheless we should still be able to just let the navigation manager either reuse existing id from a started navigation, or just generate a new one.

So does this mean that the downloadWillBegin event signals that the corresponding navigation is finished (without another navigation* event)?

Nevertheless we should still be able to just let the navigation manager either reuse existing id from a started navigation, or just generate a new one.

Do we always need a navigation for a download? I was under the impression that a successful navigation always changes the history state and downloads do not. So if we know from the start that the clicked link triggers a download, could we handle the download without a navigation?

Do we actually need some (external) spec updates here or do just we not yet align to them and the attached patches are going to fix it?

The patches I attached here are just aligning with the spec - at least from what I understand of the HTML spec.
Ultimately the download attribute should also trigger a navigation I think but that depends on the quite old html spec issue https://github.com/whatwg/html/issues/5548

I put them all in changes planned because we need to clarify with Holger that this matches what is needed for (presumably?) playwright.

(In reply to Holger Benl [:hbenl] from comment #3)

So does this mean that the downloadWillBegin event signals that the corresponding navigation is finished (without another navigation* event)?

Yes I think that's the idea, this corresponds to https://html.spec.whatwg.org/#populating-a-session-history-entry:webdriver-bidi-download-started:~:text=Invoke%20WebDriver%20BiDi%20download%20started%20with%20navigable which is in the session history step. As you can see it reuses a preexisting navigation id, generated for the actual navigation.

The previous otherwise branch leads to navigationFailed.

We don't really have navigationEnd/succeeded, so the other potential outcome would be navigationAborted (which I don't think we can hit here?) or domContentLoaded/load, which are also not going to be raised in this case. So based on the spec, clicking on a link which initiates a navigation but ends up triggering a download should trigger navigationStarted -> downloadWillBegin. If you understand the spec differently let me know, I don't really know the spec very well.

Nevertheless we should still be able to just let the navigation manager either reuse existing id from a started navigation, or just generate a new one.

Do we always need a navigation for a download? I was under the impression that a successful navigation always changes the history state and downloads do not.

It's a bit complicated, and the spec for downloads is still in flux (https://github.com/whatwg/html/issues/5548). Also note that the navigation is not successful or committed here. It's just started, which doesn't indicate much beyond "we are attempting a navigation".

So if we know from the start that the clicked link triggers a download, could we handle the download without a navigation?

That's only the case when using a download attribute, otherwise the spec clearly hits navigation started first.

Also note that Chrome passes the test I just attached here. Although I am not asserting navigationFailed events in which case I imagine we would see a discrepancy.

(In reply to Julian Descottes [:jdescottes] from comment #8)

We don't really have navigationEnd/succeeded, so the other potential outcome would be navigationAborted (which I don't think we can hit here?) or domContentLoaded/load, which are also not going to be raised in this case. So based on the spec, clicking on a link which initiates a navigation but ends up triggering a download should trigger navigationStarted -> downloadWillBegin. If you understand the spec differently let me know, I don't really know the spec very well.

That's how I understand the spec as well, I just wasn't sure if it was intentional or if the spec was still missing something.

Do we always need a navigation for a download? I was under the impression that a successful navigation always changes the history state and downloads do not.

It's a bit complicated, and the spec for downloads is still in flux (https://github.com/whatwg/html/issues/5548). Also note that the navigation is not successful or committed here. It's just started, which doesn't indicate much beyond "we are attempting a navigation".

So if we know from the start that the clicked link triggers a download, could we handle the download without a navigation?

That's only the case when using a download attribute, otherwise the spec clearly hits navigation started first.

Yes, that's the case I had in mind. But it's fine to have a navigation for those as well (especially since even these links can trigger navigations, as pointed out in https://github.com/whatwg/html/issues/5548).

Updated the current bidi spec issue for download initiated by download attributes. Currently implementations are not emitting navigationStarted in this case, we should discuss in the next spec meeting if this is OK or not. Waiting to submit patches to review until then.

Looks like the idea is to stay close to what the implementations are doing, so no navigationStarted event for the download attribute and we will actually remove the navigation id from the event as well.

https://hg.mozilla.org/mozilla-central/rev/1e67672c6a00
https://hg.mozilla.org/mozilla-central/rev/cbadad132a2f