You need to
before you can comment on or make changes to this bug.
Normally, after drawing an image from a different origin onto a canvas, toDataURL is blocked with a security exception (which is good).
The linked page has nine identical pages in iframes, each loading the same remote image and calling toDataURL. It gives output like http://philip.html5.org/misc/iframe-canvas-security/webkit-r32574.png - most of the iframes are able to successfully read the image data (which is bad). Sometimes, when revisiting the page, the unsuccessful one randomly swaps to a different location (but there's always only one). When pressing the "reload" button, all the iframes work correctly until the page is revisited.
Turns out this is not a canvas tainting bug. The issue is that the images are not being drawn to the canvas at all, and thus no canvas tainting is taking place. The data: urls that are being produced are of the empty canvas, not including the yellow image.
Removing from the security component.
The probable issue here is that the onload handler in the subframes seem to be firing before the image resource is available, and thus the drawImage is failing.
Created an attachment (id=20853) [details]
Note that the testcase has a small bug in it. It should not be slow-png.pl but instead slow-png.php.
I will add a corrected testcase below.
Created an attachment (id=20878) [details]
fixed testcase, added mail address to slow-png.php
I looked into this a bit, and this is my understanding ~
The problem is that we have multiple DocLoaders depending on the same CachedResource. The first DocLoader to request the resource gets its requestCount() bumped in Loader::load(), but subsequent loaders don't.
Later on, in FrameLoader::checkCompleted(), the DocLoader's requestCount() is checked and may return 0 since the loader isn't tracking all its resources.
I am not quite sure how to fix this without incurring a performance penalty for the common case (no shared resources between concurrent loaders.) Would love some input from someone who knows the loader code.
My understanding of window.onload is that it deliberately does not wait for images to be loaded due to that (in the general case) delaying page load.
(In reply to comment #8)
> My understanding of window.onload is that it deliberately does not wait for images to be loaded due to that (in the general case) delaying page load.
You're probably thinking of the DOMContentLoaded event. window.onload should wait for all sub-resources to finish loading. This already works in the WebKit implementation, except for this corner-case with a single resource shared between multiple simultaneously loading documents.
*** Bug 20541 has been marked as a duplicate of this bug. ***
*** Bug 29615 has been marked as a duplicate of this bug. ***
Created an attachment (id=83961) [details]
A first swing at this.
(From update of attachment 83961 [details])
Created an attachment (id=83981) [details]
Proposed patch v2
Same patch with a test.
Sorry about that, I had a little trouble figuring out how to trigger the bug 100% reliably.
(From update of attachment 83981 [details])
As discussed in the IRC, I think it would be better to try to address the underlying problem (onloads fired by ResourceLoaders instead of CachedResources that know about all the clients) rather than to add another hack of this kind. If that turns out to be massively complicated then we may need to consider something like this.
*** Bug 36208 has been marked as a duplicate of this bug. ***