spec a way to determine when an iframe fails to load

[wanderview]

It currently seems there is no good way to determine if an iframe fails to load due to a network failure. In these cases the frame ends up at a browser-specific "network failure" page. As an extra complication these network pages are considered same-origin in some browsers (blink) and cross-origin in others (gecko).

This leads us to do evil timing things in the wpt tests to try to detect failed loads:

https://dxr.mozilla.org/mozilla-central/source/testing/web-platform/mozilla/tests/service-workers/service-worker/fetch-frame-resource.https.html#34

it would be nice if we could spec an onerror for iframe in these cases. Extra bonus points for solving this problem for window.open() as well.

[domenic]

This could be covered as part of #127.

[annevk]

I'm having a bit of trouble reading the specification. Navigate has "If the resource's out-of-band metadata (e.g. HTTP headers), not counting any type information (such as the Content-Type HTTP header), requires some sort of processing that will not affect the browsing context, then perform that processing and abort these steps." which a note below it suggests that includes network errors. However, you suggest browsers do render an "error page" of sorts.

HTML also makes mention of "error page" or do nothing in a few places.

None of that is particularly great. So I guess navigate should catch "network error" somehow and then load that in a browsing context. Perhaps explicit marking the document as cross-origin since same-origin doesn't seem super helpful. If that leaks data about the specifics that might even be a security issue.

[igrigorik]

@annevk what's the security issue?

[annevk]

@igrigorik say you load https://potential-internal-google-server.com/ and the browsers were to return a same-origin error document you could use the information in that document to find out more and probe more informed.

[igrigorik]

@annevk I see. FWIW, feels that we keep circling around w3c/resource-timing#12 -- we need to come on a resolution on that. I'll try to nudge it next week.

[annevk]

From talking with @bzbarsky one problem here is that in Gecko there's no load/error event for network errors. You sorta have to wait an unspecified amount of time before error pages are a thing. It's not entirely clear why that is the case.

[wanderview]

@annevk Is that because we treat the net error as cross-origin?

[annevk]

@wanderview no, that's unrelated to that (cross-origin loads normally would give an event).

[bzbarsky]

It's due to the implementation details of how error page loads happen... I don't recall what the exact reasoning was, but maybe @smaug---- does?

[smaug----]

I don't recall, sorry. Would need to look at the blame.

[annevk]

@smaug---- could you look at blame? I'd be interested in requiring all browsers to dispatch an error event for network failures (and make the error document cross-origin).

[smaug----]

well, UA could just dispatch error event when error document is loaded, whenever that happens.

[annevk]

@smaug---- okay, if that's possible I'll see about writing tests and updating the standard. I think that'd be very useful.