OK, so I think this is fixed in SVN now. I'd appreciate any devs (or other interested parties) taking a look at the fix to verify that it meets expectations; the discussion on this was pretty long. The relevant classes are HtmlImage and HTMLImageElement, SVN revision 3769.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I forgot to mention that the final behavior is that images get downloaded only when they have an onload handler, and the onload handler gets called after successful image download.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@Daniel:
is it possible that the onload handler is executed too early with your implementation? Or is it a situation that can occur in a "real" browser?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@Marc: Yep, depending on what you consider to be "too early" ;-) Native browsers can download several things in parallel, and when they encounter an image I believe that a download is scheduled on the next available connection while HTML parsing continues. We don't have this sort of functionality (it has only been recently that we even started thinking about external CSS / images), so in the static case (an img tag w/ no JS) the HTML parsing has to wait for the image download to finish and the onload handler to execute. In the dynamic case (an img created via JS) I think we're closer to the native implementations (via the postponed action).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@Daniel: that's clear that we implement a particular, deterministic case but my question was more related to firing onload before other possible scripts in the page. Can it happen in a "real" browser? I guess that it is unlikely because parsing the rest of the page will take less time than retrieving the image, but it would be interesting to know if this is just "unlikely" but possible or if the browser first parses the page to the end.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ah, I see what you mean now. Yes, it's possible that a more faithful emulation would be to delay execution of the onload handler in the static node case until later in the page lifecycle (somewhere around body.onload, maybe). But I'm afraid I just don't know :-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Test Case
Logged In: YES
user_id=402164
Originator: NO
Started discussion in the dev mailing list to find the best way to handle it.
Assigning to Marc, as he claimed it on the dev list (so I can tell what's available and what's not).
Deassign from Marc; he was expressing a desire for the bug to be fixed, not committing to fixing it!
Original discussion raised by Ahmed:
http://www.nabble.com/How-should-we-handle-image.onload--tt9850876.html
Subsequent discussion raised by a user:
http://www.nabble.com/Image-Onload-Support-td18895781.html
OK, so I think this is fixed in SVN now. I'd appreciate any devs (or other interested parties) taking a look at the fix to verify that it meets expectations; the discussion on this was pretty long. The relevant classes are HtmlImage and HTMLImageElement, SVN revision 3769.
I forgot to mention that the final behavior is that images get downloaded only when they have an onload handler, and the onload handler gets called after successful image download.
@Daniel:
is it possible that the onload handler is executed too early with your implementation? Or is it a situation that can occur in a "real" browser?
@Marc: Yep, depending on what you consider to be "too early" ;-) Native browsers can download several things in parallel, and when they encounter an image I believe that a download is scheduled on the next available connection while HTML parsing continues. We don't have this sort of functionality (it has only been recently that we even started thinking about external CSS / images), so in the static case (an img tag w/ no JS) the HTML parsing has to wait for the image download to finish and the onload handler to execute. In the dynamic case (an img created via JS) I think we're closer to the native implementations (via the postponed action).
@Daniel: that's clear that we implement a particular, deterministic case but my question was more related to firing onload before other possible scripts in the page. Can it happen in a "real" browser? I guess that it is unlikely because parsing the rest of the page will take less time than retrieving the image, but it would be interesting to know if this is just "unlikely" but possible or if the browser first parses the page to the end.
Ah, I see what you mean now. Yes, it's possible that a more faithful emulation would be to delay execution of the onload handler in the static node case until later in the page lifecycle (somewhere around body.onload, maybe). But I'm afraid I just don't know :-)
Ok, then let's wait until a user complains ;-)