Make navigate's resource handling more explicit #1346
Conversation
Also remove the speculative 401 features that seem unlikely to ever materialize. This definitely requires more work to actually talk about responses instead of resources and more clearly tie it to the _resource_ variable from earlier in the navigate algorithm, but since all those interactions are still somewhat unclear this will have to do. Fixes #511.
| <li><p><i>Resource handling</i>: If the resource is a network error, then <span | ||
| data-x="navigate-ua-inline">display the inline content</span> with the newly created | ||
| <code>Document</code> object's <span>origin</span> set to a new <span>opaque | ||
| origin</span>.</p></li> |
There was a problem hiding this comment.
Not xrefed properly, probably concept-opaque-origin?
There was a problem hiding this comment.
This step is entirely new, right? Maybe it could be clearer by saying "display inline content indicating to the user an appropriate error"? Maybe even add a clarifying note saying something like "This is where user agents display network error pages (etc.) to the user".
ADD THIS TO THE EVENTUAL COMMIT MESSAGE: 401 is handled by Fetch.
| processed as if they had no challenge, e.g. rendering the entity body as if the response had | ||
| been 200 OK.</p> | ||
| <p class="note">This is where the network errors defined and propagated by the WHATWG Fetch | ||
| standard, such as DNS or TLS errors, end up being displayed to users. <ref spec=FETCH></p> |
There was a problem hiding this comment.
Should network error, here and above, xref to https://fetch.spec.whatwg.org/#concept-network-error ?
There was a problem hiding this comment.
Maybe this should be a follow-up issue. There are 18 occurrences of "network error" in the spec (after this change), of which probably most should be xrefed, but others occur alongside "4xx" and "5xx", and should probably be replaced with an "ok" check. I'll open a new issue.
|
LGTM with xref nit. Will open a separate issue on Fetch for something I'm confused on about 401 handling. |
|
I'll actually merge this now and leave #1363 as a cleanup for later since it's a larger problem than a single missing xref. |
|
Sorry, I didn't notice this before. It seems like we still prompt to unload the document unconditionally, though. For 204/205/ (Perhaps add a should-unload variable?) |
|
@Manishearth I'm not sure I follow that completely. Are you saying we regressed the previous text or is this a separate issue we need to address? |
|
Separate issue. I'd mentioned this in #511, "204 and 205 should require the user agent to not navigate (and not unload the current page)". The old spec didn't handle this either. |
|
I opened #1382. Hope that's okay. Will try to get to it soonish. |
|
No problem! 😄 |
Also remove the speculative 401 features that seem unlikely to ever
materialize. This definitely requires more work to actually talk about
responses instead of resources and more clearly tie it to the
resource variable from earlier in the navigate algorithm, but since
all those interactions are still somewhat unclear this will have to do.
Fixes #511.