The behavior can be seen by opening 2 tabs to the same website. In one tab load a server side script that doesn't return data for say 30 seconds. In the second tab, open a webpage on the same site with multiple images, css, etc, but nothing that would stall. What you will see if that it appears some of the image loads on the second tab are queued up in the connection from the first tab and they will not load until the web page in the first tab returns. I would provide a sample website, but this occurs for me on an internal corporate portal. If I run the same test in Firefox, the second tab will load fine, but in the Webkit nightly and production Safari, it will stall that second tab.
Without a way to reproduce the bug it's hard to investigate this. There are a number of reasons why this could happen, but the one that springs to mind is that the number of concurrent connections to a host is limited by the networking layer. I believe the limit is somewhere around 4-6 per host.
Do requests for various images, CSS, get put into a queue for a specific connection to the host? To where if queues 1-3 are not busy, but 4 is busy, then there can be requests in queue 4 that block until the connection is not busy. That seems to be the behavior I see as some images will load in the second tab, but some will block until the request in tab 1 completes. Would it be possible to rebalance the connection queues if one empties out and is not busy so as to prevent this blocking?
I have created a simple app on the google app engine to replicate this behavior. Open 2 tabs in webkit. In tab 1 open http://webkit-stall.appspot.com/ In tab 2 open http://webkit-stall.appspot.com/static/index.html Tab 1 calls a script that will pause for 8 seconds before sending data while tab 2 is all static files. What you will see is if you hit reload on tab 1 and then go to tab 2 and hit reload, tab 2 will not finish loading even though it is all static data until tab1 finishes. It is as if the requests in tab 2 get queued up in the connection that is blocked from tab 1.
This appears to have something to do with caching. If I disable the cache from the Develop Menu, then the bug does not occur.