body onLoad=this.open(blockNav.asp?sectionID=8, navigation)

navigation is an iframe and blocknav gets the content from the database and does its own onload in its body tag to load the content iframes.

Would the issue in this discussion be the reason for the problem? If so, is there a workaround?

http://bugs.webkit.org/show_bug.cgi?id=13241

That seems to contradict somewhat with what Dave Hyatt states above (though obviously not much detail in the report), and sounds as if it would actually skew results…

Keep in mind that iBench is a third-party benchmark suite originally developed by Ziff Davis Media. It was under development before Safari even existed, so to say that the benchmark is designed to penalise other browsers due to a quirk in Safari’s behaviour is quite far-fetched. The design of the benchmark is to ensure that what is being timed is consistent across browsers.

Now your point about iBench (I didn’t mention that in the original article, but since you have mentioned it I added it) – that just means you are penalising other browsers to make up for an unexpected behaviour in Safari, since scrolling can take a long time on some pages when layout was otherwise fast – opacity and fixed backgrounds in Opera come to mind here. It also means you are no longer testing just load&display times, so iBench does not represent what it is supposed to represent.

Sorry, but that is a cludge, not accuracy.

Your comments about when onload fires are valid (yes, it’s good for efficiency in some cases), but that does not contradict anything I have said about benchmark testing. The article was about benchmarking, after all.

Yes, onload does fire earlier in Safari than in other browsers. However it does not fire until all resources have been loaded. We do delay doing the first layout (if the page loaded quickly enough) until after the onload fires. This is simply common sense, since to do otherwise is to waste time doing relayouts as a result of the changes that would be executed by a typical onload handler.

Note that Firefox does not defer its first layout until after onload, but – like Safari – it also defers painting until after the onload has fired. Neither browser will paint until after the onload if the page loads quickly enough. (I ought to know. I implemented this in Firefox.)

Regarding images, Safari does wait until the image data has been fetched before firing onload, but it does not decode images until they actually paint. Again this is common sense to keep memory usage down (and is especially useful on mobile devices). Most other browsers are not very smart in this respect and aggressively decode images before firing the onload. This is neither necessary nor required to be compliant with onload (and it wastes memory and hurts performance).

Finally, regarding the ibench test itself, ibench is specifically designed to work around onload. It forces the page to lay out and scroll, causing every browser in the test to paint each page twice. It also measures the overall time of the entire run, thus ensuring that as long as your paints take longer than the timeout values used, even the paints will be incorporated into the time. It’s actually really clever.

Charlie