9582 2006-06-25 13:37:53 -0700 img.onload event ONLY fires when .src changes 2024-05-21 03:49:26 -0700 1 1 1 Unclassified WebKit DOM 417.x Mac OS X 10.4 NEW InRadar P2 Normal --- 1 jschrab webkit-unassigned ahmad.saleem792 bfulgham crschmidt dacarson eric hyongyoub.kim ian mitz sabouhallawa webkit-bug-importer oldest_to_newest 47134 0 jschrab 2006-06-25 13:37:53 -0700 Consider the following example: ------------------------------------------ <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> <head> <script type="text/javascript"> function dothis() { document.getElementById('demoImage').onload = function() { alert('done'); } document.getElementById('demoImage').src = "http://images.apple.com/main/elements/homeiconus.gif"; } function dothat() { document.getElementById('demoImage').onload = function() { alert('done'); } document.getElementById('demoImage').src = "http://images.apple.com/main/elements/homeiconus.gif"; } </script> </head> <body> <a href="#" onclick="dothis();">dothis</a> | <a href="#" onclick="dothat();">dothat</a><br /> <img src="http://images.apple.com/main/elements/homeiconus.gif" id="demoImage" alt="" /> </body> </html> ------------------------------------------ It would appear that onload events for img elements (possibly more) only will fire when there is an actual change to the .src in the above example. The "alert()'s" in the onload functions never fire because the value of src changes. This is not how other major browsers (IE 6.0 and Firefox 1.5 tested) behave - onload events always fire after they are complete, even if they don't do a whole lot in the case of unchanged content. There is a work around but it's not nice: ------------------------------------------ <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> <head> <script type="text/javascript"> function dothis() { document.getElementById('demoImage').onload = function() { alert('done'); } document.getElementById('demoImage').src = "http://images.apple.com/main/elements/homeiconus.gif?random="+Math.random(); } function dothat() { document.getElementById('demoImage').onload = function() { alert('done'); } document.getElementById('demoImage').src = "http://images.apple.com/main/elements/homeiconus.gif?random="+Math.random(); } </script> </head> <body> <a href="#" onclick="dothis();">dothis</a> | <a href="#" onclick="dothat();">dothat</a><br /> <img src="http://images.apple.com/main/elements/homeiconus.gif" id="demoImage" alt="" /> </body> </html> ------------------------------------------ With differing URL's, the src is different so onload events will fire off. But this is a waste - the browser goes off the server for images that it really doesn't need, just so events will fire off. 47230 1 9042 ap 2006-06-26 02:10:39 -0700 Created attachment 9042 test case Same test, as an attachment. 47234 2 mitz 2006-06-26 02:29:45 -0700 IIRC, the DOM specification doesn't include load events for IMG elements, so I think whether the current behavior is a bug or not is mostly a question of what Firefox and IE (plan to) do. At least, the behavior of SCRIPT and other load events should be considered at the same time. 48133 3 dacarson 2006-07-03 19:46:23 -0700 I wonder if the onLoad event should fire when (a) the first block of data arrives, or (b) when the full response has arrived or (c) when the image has been converted to a platform bitmap or (d) when it has been rendered. Comment #0 says that it fires when it is complete - but what is complete? If the image is not visible, then it may not be loaded. If the image is hidden, then it may not be fully converted to a bitmap, maybe just the height and width is available at this point. Need to do some testing with IE and FF. 48178 4 jschrab 2006-07-04 09:48:06 -0700 I would like to make motion that it should be "(d) when it has been rendered." While it may seem selfish for me to say so, my real-world need that lead to the discovery of this bug/quirk was in an effort to implement some DHTML cross-fade effects. I wanted to make sure that my opacity=0 image was loaded before my transition began. It would seem to me that the usefulness of .onload, particularly for images, is to be notified that an image is ready-to-go. And ready-to-go, I would say, means rendered. Of course my case here is for a transparent image (via opacity style) or otherwise not visible image may lead to a fine point of "what do you mean by 'rendered'?" 48203 5 ddkilzer 2006-07-04 15:37:09 -0700 (In reply to comment #3) > I wonder if the onLoad event should fire when > (a) the first block of data arrives, or > (b) when the full response has arrived or > (c) when the image has been converted to a platform bitmap or > (d) when it has been rendered. What do other browsers do? Can we tell what MSIE and Firefox do? 58500 6 mrowe 2007-10-14 06:21:18 -0700 *** Bug 15499 has been marked as a duplicate of this bug. *** 58501 7 crschmidt 2007-10-14 06:37:42 -0700 My experience with FF + IE has always been 'at the time onload is called, swapping the image from display:none to display:block results in a fully rendered image being displayed. That probably only makes it clear that it's not 'a', described below, since anything else could happen within a repaint, and there's no way to tell the difference visually. The current behavior in Safari seems to be matched by Opera. This was reported as part of the OpenLayers project: http://trac.openlayers.org/ticket/758 (I would love to see this fixed, as, at the moment, OpenLayers is relatively unusable under Safari for many users.) 58512 8 eric 2007-10-14 10:47:00 -0700 This is kinda related to bug 15484. 1188495 9 hyongyoub.kim 2016-04-28 20:36:31 -0700 I know this issue has seen no action for 9 years. Here is a ping that this issue does matter in the real world. Many sites use this "load the same source twice + onload event" technique to load images asynchronously and then display them when they are already in the memory cache. Looks like Chromium fixed this last year. https://codereview.chromium.org/1047563002 The second load event does not fire because the following check in ImageLoader. http://trac.webkit.org/browser/trunk/Source/WebCore/loader/ImageLoader.cpp#L217 Tried simply pretending the images are always different. It seems to work okay, but not sure about any side effects this would have on CachedImage::didAddClient and CachedImage::didRemoveClient. 1881128 10 webkit-bug-importer 2022-07-06 14:45:52 -0700 <rdar://problem/96549817> 2036697 11 ahmad.saleem792 2024-05-21 03:49:26 -0700 I took test cases from Blink commit and it seems that WebKit ToT (279051@main) passes them now. Blink Commit - https://github.com/chromium/chromium/commit/3a2965e93805f4cf213b8c1f84ed8141145f951b It would be good to import these tests IMO. 9042 2006-06-26 02:10:39 -0700 2006-06-26 02:10:39 -0700 test case img-onload.xhtml application/xhtml+xml 986 ap PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBYSFRNTCAxLjAgVHJhbnNpdGlvbmFs Ly9FTiIKICAgICAgICAiaHR0cDovL3d3dy53My5vcmcvVFIveGh0bWwxL0RURC94aHRtbDEtdHJh bnNpdGlvbmFsLmR0ZCI+Cgo8aHRtbCB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMTk5OS94aHRt bCIgeG1sOmxhbmc9ImVuIiBsYW5nPSJlbiI+CjxoZWFkPgogICAgICAgIDxzY3JpcHQgdHlwZT0i dGV4dC9qYXZhc2NyaXB0Ij4KICAgICAgICBmdW5jdGlvbiBkb3RoaXMoKSB7CiAgICAgICAgICAg ICAgICBkb2N1bWVudC5nZXRFbGVtZW50QnlJZCgnZGVtb0ltYWdlJykub25sb2FkID0gZnVuY3Rp b24oKSB7IGFsZXJ0KCdkb25lJyk7IH0KICAgICAgICAgICAgICAgIGRvY3VtZW50LmdldEVsZW1l bnRCeUlkKCdkZW1vSW1hZ2UnKS5zcmMgPSAiaHR0cDovL2ltYWdlcy5hcHBsZS5jb20vbWFpbi9l bGVtZW50cy9ob21laWNvbnVzLmdpZiI7CgogICAgICAgIH0KICAgICAgICBmdW5jdGlvbiBkb3Ro YXQoKSB7CiAgICAgICAgICAgICAgICBkb2N1bWVudC5nZXRFbGVtZW50QnlJZCgnZGVtb0ltYWdl Jykub25sb2FkID0gZnVuY3Rpb24oKSB7IGFsZXJ0KCdkb25lJyk7IH0KICAgICAgICAgICAgICAg IGRvY3VtZW50LmdldEVsZW1lbnRCeUlkKCdkZW1vSW1hZ2UnKS5zcmMgPSAiaHR0cDovL2ltYWdl cy5hcHBsZS5jb20vbWFpbi9lbGVtZW50cy9ob21laWNvbnVzLmdpZiI7CiAgICAgICAgfQogICAg ICAgIDwvc2NyaXB0Pgo8L2hlYWQ+Cgo8Ym9keT4KICAgICAgICA8YSBocmVmPSIjIiBvbmNsaWNr PSJkb3RoaXMoKTsiPmRvdGhpczwvYT4gfCA8YSBocmVmPSIjIiBvbmNsaWNrPSJkb3RoYXQoKTsi PmRvdGhhdDwvYT48YnIgLz4KICAgICAgICA8aW1nIHNyYz0iaHR0cDovL2ltYWdlcy5hcHBsZS5j b20vbWFpbi9lbGVtZW50cy9ob21laWNvbnVzLmdpZiIgaWQ9ImRlbW9JbWFnZSIgYWx0PSIiIC8+ CjwvYm9keT4KPC9odG1sPgo=