Keep track of errors so they can be exposed (if desired) in UX (and maybe API at some point)

[jakearchibald]

https://fetch.spec.whatwg.org/#http-fetch 3.3 currently creates a generic network error. This means browsers display a generic error message if a navigation fails.

Ideally the browser should be able to display more relevant information like "bad certificate", "DNS failure", "You are offline", which I guess involves passing the error response back to the caller (navigation in this case).

@annevk suggests there are cases where this is a security issue, so a TODO is to find out what these are & when we can safely pass the error on.

[annevk]

Are we talking about user-facing errors? Those are not typically exposed as they live in cross-origin documents.

If we're talking about exceptions coming from Fetch that'd be something else.

[jakearchibald]

I'm talking about user-facing errors. If the browser is deciding which error to show as part of navigation, by returning a generic error in 3.3 we're reducing its usefulness.

Or does this stuff live outside of spec land?

[annevk]

We do handle it as part of navigation in HTML. And I think you're correct that the flow in the standard should make sure that if the user agent wants to expose more detail there, that it's actually available. But in large part this is UX so user agents are already free to do what they want (as long as the document they create meets certain invariants which are probably not interoperable at the moment).

[RealAlphabet]

It's crazy that this has still not been discussed after 7 years. Despite the various requests from the error monitoring libraries.