Bug 18762 - Window.onload is firing before image resources are loaded (if loading in multiple documents at once)
: Window.onload is firing before image resources are loaded (if loading in mult...
Status: NEW
Product: WebKit
Classification: Unclassified
Component: Page Loading
: 528+ (Nightly build)
: All All
: P2 Normal
Assigned To: Nobody
http://philip.html5.org/misc/iframe-c...
: InRadar
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-04-26 16:00 PDT by Philip Taylor
Modified: 2011-06-06 16:02 PDT (History)
20 users (show)

See Also:


Attachments
testcase (18.54 KB, patch)
2008-04-27 15:11 PDT, Sam Weinig
no flags Details | Formatted Diff | Diff
fixed testcase, added mail address to slow-png.php (18.57 KB, text/plain)
2008-04-28 16:18 PDT, hahn.seb
no flags Details
Proposed patch (9.71 KB, patch)
2011-02-26 19:50 PST, Andreas Kling
abarth: review-
Details | Formatted Diff | Diff
Proposed patch v2 (12.38 KB, patch)
2011-02-27 11:04 PST, Andreas Kling
koivisto: review-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Philip Taylor 2008-04-26 16:00:37 PDT
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.
Comment 1 Sam Weinig 2008-04-26 17:44:08 PDT
<rdar://problem/5892542>
Comment 2 Sam Weinig 2008-04-26 18:23:26 PDT
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.
Comment 3 Sam Weinig 2008-04-27 14:06:17 PDT
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.
Comment 4 Sam Weinig 2008-04-27 15:11:05 PDT
Created attachment 20853 [details]
testcase
Comment 5 hahn.seb 2008-04-28 16:10:01 PDT
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.
Comment 6 hahn.seb 2008-04-28 16:18:21 PDT
Created attachment 20878 [details]
fixed testcase, added mail address to slow-png.php
Comment 7 Andreas Kling 2010-06-27 10:10:08 PDT
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.
Comment 8 Oliver Hunt 2010-06-27 12:35:56 PDT
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.
Comment 9 Andreas Kling 2010-06-27 13:15:06 PDT
(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.
Comment 10 Andreas Kling 2010-07-11 15:32:05 PDT
*** Bug 20541 has been marked as a duplicate of this bug. ***
Comment 11 Mihai Parparita 2010-10-11 14:36:58 PDT
*** Bug 29615 has been marked as a duplicate of this bug. ***
Comment 12 Andreas Kling 2011-02-26 19:50:08 PST
Created attachment 83961 [details]
Proposed patch

A first swing at this.
Comment 13 Adam Barth 2011-02-26 21:32:29 PST
Comment on attachment 83961 [details]
Proposed patch

No test?
Comment 14 Andreas Kling 2011-02-27 11:04:59 PST
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 15 Antti Koivisto 2011-02-28 05:53:53 PST
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.
Comment 16 Andreas Kling 2011-03-02 06:15:40 PST
*** Bug 36208 has been marked as a duplicate of this bug. ***