Ian Hickson wrote:
As far as I can tell, as specced, there isn't a race condition (other
than the inherent network race condition).
http://www.whatwg.org/specs/web-apps/current-work/#delay-the-load-event
In this case:
<body onload="2">
<img onload="1; image = new Image(); image.src = 'test'; image.onload = 3">
The main 'load' event is queued as soon as there is nothing left that
depends on it -- which happens as soon as the <img> load event was queued
up, but before it runs. So the handlers run in the order given (1, 2, 3).
The testcase I was thinking of is:
<body onload="3">
<img onload="1; image = new Image(); image.src = 'test';
image.onload = 2" src="foo">
<img src="bar">
In Gecko, on this testcase, the handlers always run in the order 1, 2, 3.
In your spec, if I understand it correctly, they can run in the order 1,
2, 3, or they can run in the order 1, 3, 2, depending on the order in
which foo and bar load (and even more precisely, the order in which bar
loads and the load event for foo runs). While this is pretty similar to
the inherent network race condition (you have no way to predict whether
the load for foo or bar will complete first), it's not quite the same.
In particular, in this case there is a simple manner of eliminating the
race without very much sacrifice (e.g. without having to serialize
network requests or anything silly like that).
Again, I think there are pros and cons to both approaches; it's not
clear to me how big a deal the race above is, and it's not clear to me
what the benefits of not waiting for the "test" load before firing
onload are. But it's also not clear to me what the benefits of waiting
for it would be. Gecko's behavior is largely a result of the load event
firing sync and the need to have it fire after image load events. It's
just not black-box-equivalent to what you currently have specced; that's
all I was saying.
-Boris
