Summary: If a webpage includes many IMGs whose SRCs cannot be loaded, a very long time (several tens of seconds for ~70 images) may elapse before any more of the page is displayed, during which mozilla.exe is completely unresponsive (all windows), the CPU is maxed out, and all other applications are sluggish. This will typically happen if a page that uses partial URLs (either relative or absolute) to avoid repeating "http://www.sitename.com/" at the beginning of every SRC URL is saved to a local machine without all the images (or adjusting the URLs). It could also happen if the page belongs to a site with a separate images server that is unresponsive or poorly responsive. To Reproduce: 1. Open Task Manager and minimize it to see CPU load during test (NT) (or equivalent for another platform). 2. View the "66 unloadable images" testcase attachment to this report and start timing. 3. Observe the scrollbar: quickly, the bar portion shrinks to about one quarter of the scrollbar (for a ~700 pixel tall window, ymmv) and then, about once every second or two, it shrinks by another pixel. 4. Observe the CPU meter in the taskbar tray: it will stay pegged until the page displays. 5. Click once or twice in the lower part of the scrollbar. 6. Wait some more, and note the duration when the page displays. The page will scroll now based on the step five click(s). 7. Go back to this page and view the "66 loadable images" testcase. 8. In a second or two you should have your page. Result: The "66 unloadable images" testcase (based on the Communicator version of the Bug 7732 URL) takes tens of seconds to display, and evidently much is going on under the hood. The [STOP] button does not stop processing. The "66 loadable images" testcase, identical except that the IMG SRC URLs have been made complete, displays almost immediately. (The table showing numbers for fifty companies will also have 50 lines with nothing more than "1x1trans" in them. This is a distinct bug, but see the speculation below) Expected: The "66 unloadable images" testcase takes at most a few seconds more than the "66 loadable images" testcase to load. It will take some time to determine that the images are not coming, so the timing could not be identical. Following is an extract from an Apache 1.3.9 log running on Windows NT, showing the GETs for the unloadable images. Note that "1x1trans.gif" appears 50+ times in the page, but it was only requested once. Note also that all four GETs took place within 3 seconds. 127.0.0.1 - - [17/Oct/1999:01:54:43 -0400] "GET /inc/images/1x1line.gif HTTP/1.0" 404 331 "-" "Mozilla/5.0 [en-US] (WIN95; I)" 127.0.0.1 - - [17/Oct/1999:01:54:45 -0400] "GET /testcases/images/jubak6.gif HTTP/1.0" 404 336 "-" "Mozilla/5.0 [en-US] (WIN95; I)" 127.0.0.1 - - [17/Oct/1999:01:54:46 -0400] "GET /inc/images/star1.gif HTTP/1.0" 404 329 "-" "Mozilla/5.0 [en-US] (WIN95; I)" 127.0.0.1 - - [17/Oct/1999:01:54:46 -0400] "GET /testcases/1x1trans.gif HTTP/1.0" 404 331 "-" "Mozilla/5.0 [en-US] (WIN95; I)" Speculation: If the behaviours noted in Bug 16619 and Bug 16621, where unloadable IMGs are given their filenames as substitute ALTs, after Gecko reserves their dimensions and then removes the box for those dimensions, takes even a second, it could be the root cause of this bug. This would be congruent with the behaviour noted in step 3 above, if the 50 rows in the table meant to be 1-pixel spacer lines each had to be resized one-by-one, thrice: (a) to make room for the height of "1x1trans" (1 pixel) (b) to remove the reservation for the height of "1x1trans" (c) to make room for the height of the string "1x1trans" Occurs on: 1999-10-15-11-M11 on Windows NT.

It seems that both Bug 16619 and Bug 16621 are considered DUPLICATEs of Bug 1994 (which is a frankenbug if I've ever seen one). Reading Bug 1994, and also Bug 5764, the discussion tends to support the speculation in the original report: if an image cannot be loaded, the filename is used as the ALT text, and the ALT text becomes inline. Of course, at that, there is no good reason why doing that to 66 images would take over a minute.

DUP of 11702. Table incremental reflow performance *** This bug has been marked as a duplicate of 11702 ***

This is a duplicate of 11702.