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.

[annevk]

So looking into this there are a couple of difficulties:

1. Tests: we can maybe use "https://example.invalid/" as that's guaranteed to never resolve I believe, but unclear if web-platform-tests allows that.
2. Actually passing through the whole loading pipeline that this needs to result in an error event is a little tricky. We should probably start by defining error pages more clearly.

[annevk]

Poking at this a bit more there's also quite a variety in how errors are handled (I think we might have issues on that already), such as test://example.invalid/ resulting in an error page in Firefox and about:blank in Chrome.

[annevk]

Invalid URL schemes are #1446.

[rstoneIDBS]

Having just come across this same issue (again) I wondered if any progress has being made on this?

In our case we are embedding external content (that uses a postMessage API to communicate with the host page) in our page but want to be able give our users a nicer experience than a 'browser broken page' if the external server is down.

Currently we are relying on a setTimeout that is triggered if we don't receive a message from the IFRAME in a reasonable amount of time but this is far from ideal. An 'onerror' would seem like an ideal companion to 'onload'.

[annevk]

Given the discussion at #1230 (comment) I don't think this can be fixed. At best we could create a special LoadEvent class that indicates the distinction between successful load and failure load, but I don't think dispatching a separate event is web compatible, however weird that is given other fetch contexts.

[rstoneIDBS]

Thanks for the update :)

It seems crazy that we have to rely on a horrible setTimeout hack to handle this, adding some way to do it in a non-fragile manner would be really useful.

[Arun-Josh]

I will hide the Iframe from UI and use Window.postMessage() and send a message from the iframe to the main page. When the listener in the parent gets that message from the iframe, I'll make the iframe visible.

This is the best I could think of. 😐

Advantage: This works even if the parent domains and iframe domain are different

Limitations: U should have permission to modify code on the page embedded in the iframe.