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
: WebKit
Page Loading
: 528+ (Nightly build)
: All All
: P2 Normal
Assigned To:
: http://philip.html5.org/misc/iframe-c...
: InRadar
:
:
  Show dependency treegraph
 
Reported: 2008-04-26 16:00 PST by
Modified: 2011-06-06 16:02 PST (History)


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


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2008-04-26 16:00:37 PST
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 From 2008-04-26 17:44:08 PST -------
<rdar://problem/5892542>
------- Comment #2 From 2008-04-26 18:23:26 PST -------
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 From 2008-04-27 14:06:17 PST -------
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 From 2008-04-27 15:11:05 PST -------
Created an attachment (id=20853) [details]
testcase
------- Comment #5 From 2008-04-28 16:10:01 PST -------
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 From 2008-04-28 16:18:21 PST -------
Created an attachment (id=20878) [details]
fixed testcase, added mail address to slow-png.php
------- Comment #7 From 2010-06-27 10:10:08 PST -------
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 From 2010-06-27 12:35:56 PST -------
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 From 2010-06-27 13:15:06 PST -------
(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 From 2010-07-11 15:32:05 PST -------
*** Bug 20541 has been marked as a duplicate of this bug. ***
------- Comment #11 From 2010-10-11 14:36:58 PST -------
*** Bug 29615 has been marked as a duplicate of this bug. ***
------- Comment #12 From 2011-02-26 19:50:08 PST -------
Created an attachment (id=83961) [details]
Proposed patch

A first swing at this.
------- Comment #13 From 2011-02-26 21:32:29 PST -------
(From update of attachment 83961 [details])
No test?
------- Comment #14 From 2011-02-27 11:04:59 PST -------
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.
------- Comment #15 From 2011-02-28 05:53:53 PST -------
(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.
------- Comment #16 From 2011-03-02 06:15:40 PST -------
*** Bug 36208 has been marked as a duplicate of this bug. ***