[whatwg] [CORS] WebKit tainting image instead of throwing error

[Odin Hørthe Omdal]

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