Window.onload is firing before image resources are loaded (if loading in multiple documents at once)

• Component: Page Loading
• Status: NEW ---

[Philip Taylor]

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.

[Sam Weinig]

<rdar://problem/5892542>

[Sam Weinig]

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.

[Sam Weinig]

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.

[Sam Weinig]

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

[Andreas Kling]

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.

[Oliver Hunt]

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.

[Andreas Kling]

(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.

[Andreas Kling]

*** Bug 20541 has been marked as a duplicate of this bug. ***

[Mihai Parparita]

*** Bug 29615 has been marked as a duplicate of this bug. ***

[Andreas Kling]

Created attachment 83961 [details]
Proposed patch

A first swing at this.

[Adam Barth]

Comment on attachment 83961 [details]
Proposed patch

No test?

[Andreas Kling]

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.

[Antti Koivisto]

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.

[Andreas Kling]

*** Bug 36208 has been marked as a duplicate of this bug. ***

[Sam Sneddon [:gsnedders]]

*** Bug 243127 has been marked as a duplicate of this bug. ***