If the CORS-check did not succeed on <img src=http://crossorigin.example.net crossorigin>, this should happen according to spec:
Discard all fetched data and prevent any tasks from the fetch algorithm from being queued. For the purposes of the calling algorithm, the user agent must act as if there was a fatal network error and no resource was obtained. If a CORS resource sharing check failed, the user agent may report a cross-origin resource access failure to the user (e.g. in a debugging console).
<http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#potentially-cors-enabled-fetch> In this scenario an author wanting to do some canvas processing with the image, will be able to check img.onerror to see whether she can use that image. The image won't load on a failed check. Gecko does this. WebKit, on the other hand, only taints the image and loads it anyway, breaking the spec. The error will instead crop up in a way that is more verbose and harder to miss when she tries to read the image data out. Is WebKit's method a lesser surprise than the image just not showing up (if they don't check for thrown error)? It'd be nice to hear why it's implemented like that, if there are any good reasons. WebKit's method seemed most obvious to me at first, but after investigating a bit I'm not sure anymore... -- Odin Hørthe Omdal Core QA, Opera Software
