Does this work in other browsers? YES!


It works according to specification in Firefox and Internet Explorer.

SVG is not a plugin, so issue 445557 still seem like the place for this - it seems only a single case was fixed there so far.

I opened this bug in response to what George said about asking the SVG team.
I realise that SVG is not a plugin but that is what everything that handle what is run in an object Element is called in the spec and George (who created the current patch in Chromium) also calls it a plugin. So the plugin thing is just a matter of perspective.

From George:

> Hello Jon, 
>
>  Thanks for clarifying the issue you see. I believe the plugin would have started the load of the resource and hence it is *probably* the plugin which is emitting the load event - I say this from my memory though - I did try a patch which emitted a load event(if-not-fail case) , but then I ended up seeing two load events - my guess is the second load event(other than the load emitted by my patch) was the plugin itself. 
>
> Might be good to ask the SVG team what their thoughts are.
>
> HTH,
> Thanks,
> George.

You might want to consider opening this again as it seems that the Blink>Loader can not take responsibility for emitting events (should be handled by the component/plugin that handle the specific data type).

No, the spec does not refer to "everything in an <object>" as a plugin. (It differentiates between "a type that the user agent supports" [SVG is in this bucket in Blink] and "plugin" - per spec the former is even supposed to take precedence.) But you are right - what we ultimately call it is irrelevant. Implementation-wise however it is not irrelevant if something loads as a plugin or as a "type that the user agent supports" - especially in cases like with SVG where we create a nested browsing context.
Now, this is brings us to why this is a Blink>Loader (or Blink>HTML>Object): If the request fails with a 404, we haven't even reach the stage where how something should be handled has been determined - and even if the 404 error page were to use "image/svg+xml" as its content type, we should still show fallback content and not said error page. Also, if you were to load HTML into your <object> (still with the 404), the result would likely be the same, because the same loading pipeline is used.
So, yes, I think this is issue 445557 and the components applied there are the right ones. Maybes the managers of said components doesn't consider that high enough prio (it's among the top-50 starred bugs for Loader.) It may very well be that I'll end up fixing it myself though...

Thank you for the very detail explanation!

I should note that a unresolved DNS call will result in an error event being emitted. E.g. an URL like 'http://does.not/exist', will emit an error event.

https://bugs.chromium.org/p/chromium/issues/detail?id=445557#c18

Yes, that will fail very early (and won't even generate a request), and dispatches the 'error' event at that point. (The code for loading things into <object> is a royal mess, if that hasn't become clear yet...)