Overview: If a link on a large page with many images is opened in a new window while the first page continues to load, loading of the second page will be delayed beyond reasonable user expectations, on a slow link. Steps to Reproduce/Actual Results: 0. 28.8 modem link required to reproduce at all similarly to the following. 1. Load URL. 2. Once enough text/table content arrives, right-click on a link. (10s elapsed) 3. Select "Open link in new window" from the context menu. 4. Resize/move new window so that the statusbars of both are visible (20s elapsed) 5. Wait and watch: the "Looking up host" message in the second window's status bar will arrive after ~150s. 6. By 250s, the first page is done, and the second page is just getting well underway. By 400s, the second page will finish. During the entire 400s, the modem is receiving data flat out. It looks like the first page (which does have plenty of images) may be monopolizing the available HTTP connections. Expected Results: The second page will get started connecting to the server and actually loading data much sooner, within 10s after new window finishes initializing. The two pages will share the link, perhaps not 50/50, but in a somewhat balanced manner. If there is a hard limit on the number of simultaneous HTTP connections, would it be reasonable to not give the first page another when it is done with one, until the second page can at least open its first connection? Tested with: 1999-11-16-08-M12 nightly binary, Windows NT 4.0sp3. Additional Information: 1. Packet size on the NT box was 1500 (~1.2s at the actual 26.6 data rate), default receive window, packets probably were not fragmented at any point. 2. Consistent results loading http://www.wb.com (Warners Bros, another image-rich site) and its Table of Contents page simultaneously: 120s to initial data in second window, 180s to first page done, 240s to second page done. 3. This bug found testing a variation on the procedure in Bug 16484.

Assigning to Travis to verify with new webshell redesign.

Sorry, wrong bug. I meant to assign this one to Gordon.

Bulk move of all Necko (to be deleted component) bugs to new Networking component.

Windows dns lookups are now asynchronous, so this may be fixed. We need to test a recent build on a 28.8 modem link.

DNS lookups are unlikely to be the main problem here. The links to stories at this site all go to the same host as the main page at the URL above, and the images all appear to come from the same one other host. What does look likely to be the problem is the availability of sockets. At 28.8, and with 1500-byte packets, fewer than 2 packets can be received per second. This site has 70-80 images on the main page. Of those, many call one of two single pixel gifs, but at least 25 are in the 3-10 KB size range. If all available sockets get used by requests for these images immediately, it could be tens of seconds before a socket becomes available for another page. Quoting Comments From fur@netscape.com 09/17/99 09:27, in bug 12155, "[4.xP] should load non-displayed images less aggressively": >Say, for the sake of argument, that the limit is four >simultaneous connections.) If, say, a page commences loading of ten >"low-priority" images followed by some "high-priority" images, none of the >high-priority images will even *start* loading until seven of the low-priority >images complete loading. I can't really think of a simple way to work around >that problem in the Navigator. Nor can I, but I can think of a simple solution to the problem seen here: never let an IMG load have the last socket. Especially since Mozilla includes Mail/News, it's just bad form to let one page monopolize the connection. (BTW, this can't just be a DUP of bug 12155 - that bug is about relative priority of loading images vs. images, this bug is about relative priority of loading images vs. .html, .css, .xml, etc. - although if image loading is made less aggressive, it ought to help the testcases here) Retested twice, once in the early afternoon EST, once in the wee hours, and got comparable results both times - at least a 120s wait for the second page to even start loading. Retested with: 2000-01-12-10-M13 nightly binary on Windows NT 4.0sp3, connection at 26.6 over a modem two hops from a core Sprintlink router.

Moving post beta bugs to M18 which is now the post-beta milestone.

This is not a DNS issue. Back to gagan for reassignment.

mass move, v2. qa to me.

This affects 200201108 and any other build I've tried for the past half-year on Linux. If I hit ctrl+n and try to load something, and it's not loaded a few seconds later (I'm on high-speed DSL), the only solution is to go back through all the other windows, look for a running throbber, and hit stop. Pages like IMDB.com or Kuro5hin.org or Slashdot.org tend to trigger this misbehaviour.

hey darin, is this problem that we are tying up all of the available socket transports loading the first page? -- rick

rick, yes that sounds like the problem here. the HTTP connection handling code needs to better prioritize pending transactions. perhaps we could simply give higher priority to channel's with the LOAD_DOCUMENT_URI load flag set. at any rate, i think this bug belongs to Networking:HTTP

Tried to improve summary. Please let me know if you object. What is the best way of giving other connections more priority, choking the TCP window of the connections?

-> default owner