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 r32574.png">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.
<rdar://problem/5892542>
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 attachment 20853 [details] testcase
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 attachment 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 attachment 83961 [details] Proposed patch A first swing at this.
Comment on attachment 83961 [details] Proposed patch No test?
Created attachment 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.
Comment on attachment 83981 [details] Proposed patch v2 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. ***
*** Bug 243127 has been marked as a duplicate of this bug. ***