Ian Hickson wrote:
The spec requires the page 'load' event to be fired asynchronously. (There's no black-box way to distinguish this from the case of waiting for the other 'load' events to have fired, as far as I can tell.)
Phrased that way, yes. But maybe I wasn't clear on the exact behavior Gecko has here. For image load events, not only does the async event prevent the page load from firing until after it has fired, but it also prevents _checking_ whether the page load should fire until after it has fired. So if the image load event has a listener that starts new network requests, the page load would not fire until after those requests complete. In your proposed model above, whether it does or not depends on the precise order in which the image's async load event races with other network access. If it fires before all other network access is complete (and therefore before your proposed async page load event has been posted), the page load event will wait for the load started from the onload handler. If not, then it won't.
There are pros and cons to both setups, I guess; the race above is no worse than a network request whose completion would trigger onload racing against a timeout that starts a network request...
-Boris
