and if we don't want carry over to be the default for non-Navigation API navigations, should we add a

enum NavigationStateLifetimeBehavior {
  "none",
  "carryOver"
}

value to the options of the navigation api methods (including updateCurrentEntry)?

So for Ladybird, IÆve implemented support for downloading application/octet-stream resources, and for other content types we don’t support. See https://github.com/LadybirdBrowser/ladybird/issues/10238. And now I’m at the point of essentially just trying to cleanly retrofit/align a “hook” (as it were) for my already-implemented (conforming) handle-as-a-download behavior with the actual spec requirements.

So I‘m looking at step 3 and step 4 of https://html.spec.whatwg.org/multipage/browsing-the-web.html#loading-a-document.

And I’m not implementing step 3 at all — because we’re not going to do “displaying some sort of inline content, e.g., a native rendering of the content or an error message”.

So OK then I move on to step 4. We’re not going to do “Hand-off to external software”. What we‘re doing is just “handle as a download”.

My problem is: The language for that step 4 doesn’t normatively state anything that actually seems to allow me to conformantly do “handle as a download” in this case.

Instead, the language there just says kind of hand-wavingly alludes to the possibility that there are cases where “an unknown type that will be processed by handle as a download”. But never says how to actually normatively make that decision.

So the https://html.spec.whatwg.org/multipage/links.html#handle-as-a-download algorithm is not actually called normatively for this case — though it is for related Content-Disposition: attachment case.

Anyway yeah what you said about splitting would certainly seem to make sense. What I can say implementation-wise at least is: The user behavior (described in the issue I linked to) has caused our implementation of https://html.spec.whatwg.org/multipage/browsing-the-web.html#loading-a-document to get hit. And unless we make some change, then we end up just spinning there in the way way the user describes.

So, we’ve gotta do something here. We’re already in that code, and we’re at that point, and we’ve gotta do something different.

We know we are not going to hand off to an external app. And we know we are not going to try to display the content inline. We could display an error message. But then we’d just be (unnecessarily) completely blocking the user from getting (to) the resource.

So we already know we want to just download the resource for the user. And I can do that (and already implemented it). It’s just a question of kind of trying to make that OK as far as the spec requirements go.