Large blank space at top, requires a scroll down for a page before you see the data.
There is a little more to it than only 'large blank space at top'. The page begins to lay itself out a second time, duplicating portions of the content, and is apparently 'loaded' from the network a second time (see below). At first I thought this might be bug #2701 (or bug #5526), where <STYLE> tags in the <BODY> cause content to be duplicated. But there are no stray <STYLE> tags in this page. If I start viewer fresh, with an empty cache file, I get the layout problem noted above. If I subsequently re-load the page, the macro layout of the page is correct; there is no double layout/big blank space. (There are other bugs but not this macro one). Here's the DOS output. Note the double load of both the main page [(1b),(2b)] and of an <IFRAME SRC> document (the ad banner) [(1a),(2a)]. However, when I reload the page, there is no 'double-clutch' [(3a),(3b)] which I assume may have something to do with the cache and timing issues. (Note: this test is repeatable for my setup. Testing with Apr28 build (win95) opt). C:\mozBin\apr28\bin>deltree /y cache Deleting cache... C:\mozBin\apr28\bin>viewer -v -M nsComponentManager: Using components dir: C:\MOZBIN\APR28\BIN\components Going to create the event queue Reading file... Reading file...Done Loading file:///C|/MOZBIN/APR28/BIN/res/samples/test0.html took 16260 milliseconds Crawler: done loading file:///C|/MOZBIN/APR28/BIN/res/samples/test0.html [This is where I start my one (and only one) load of the page.] (1a) Loading http://ads.admonitor.net/adengine.cgi?F8|1001|1|iframe|C||| took 54100 milliseconds Crawler: done loading http://ads.admonitor.net/adengine.cgi?F8|1001|1|iframe|C||| (1b) Loading http://www.aint-it-cool-news.com/ took 54820 milliseconds Crawler: done loading http://www.aint-it-cool-news.com/ (2a) Loading http://ads.admonitor.net/adengine.cgi?F8|1001|1|iframe|C||| took 55040 milliseconds Crawler: done loading http://ads.admonitor.net/adengine.cgi?F8|1001|1|iframe|C||| (2b) Loading http://www.aint-it-cool-news.com/ took 55150 milliseconds Crawler: done loading http://www.aint-it-cool-news.com/ [This is where I reload (select in location window and hit enter).] (3a) Loading http://ads.admonitor.net/adengine.cgi?F8|1001|1|iframe|C||| took 28020 milliseconds Crawler: done loading http://ads.admonitor.net/adengine.cgi?F8|1001|1|iframe|C||| (3b) Loading http://www.aint-it-cool-news.com/ took 28240 milliseconds Crawler: done loading http://www.aint-it-cool-news.com/ C:\mozBin\apr28\bin>
Another one for the master.
When there is a linked stylesheet (existant file or not), a style part and a script part a table filled with more than 2^14=16384 characters is reloaded and displayed again. The table cell seems to be read one line at a time and the restart of the table is done when the present line would cause the table cell to be larger than the limit. The relayouted table looks quite correct.
When trying to get rid of the "file not found" error at the load of the linked stylesheet, I discovered that if you link to an existing file, the page will work. Looking at the original URL, that page too links to an nonexisting style sheet. I might be something in the handling of failed loads of linked style sheet.
Testing with build made 07/31/99 07:00 and now the testcase makes the browser quit without comment. Nothing displayed in the console about loading the page either. By the way, why has this bug target milestone M15?
Bumping severity and clearing milestone since this testcase now causes the browser not only to fail to show the page but to quit the entire program. Only output: Document http://bugzilla.mozilla.org/show_bug.cgi?id=5847 loaded successfully Document: Done (1.993 secs) WARNING: cell content 02F5A170 has large max element width 204870 WARNING: cell content 02F5A170 has large width 204870
Please don't fiddle with severity/priority/milestone - those are used by the engineers to order their bugs. If you have a problem with a bugs priority, please use email to the bug owner to discuss the situation. Thanks!
The crash bug is fixed (it was due to bug #12881 which has been fixed). The layout of the page is flawed, however, because a SCRIPT tag inside of an IFRAME is being evaluated. Currently we flush out the current pending content before evaluating a script tag; this results in a broken layout frame tree because we don't send the right notifications afterwords. This should get fixed by the same logic that fixes the incremental content sink bug (#854), however the issue with evaluating the script in an IFRAME still needs fixing (which I have done). Since we already have a bug about incremental reflow I'm going to make this a dup of that so that we can test out the script's in random places issue later on. *** This bug has been marked as a duplicate of 854 ***
Marking duplicate of 854.