655760 - Pages containing HTML tables may be displayed only when completely loaded

Status: RESOLVED DUPLICATE of bug 655682

(Firefox :: General, defect)

Description

[Karl Riedling]

User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0.1) Gecko/20100101 Firefox/4.0.1

The problem showed up in a web-based image database that traverses a number of directories with hundreds of image files each and generates a database record and a preview image if an image is not yet in the database. Checking for the presence of an image in the database takes a small fraction of a second; scaling the image requires about two seconds per image. The progress of this operation is reported as a series of HTML tables, with one table per directory and one table row per file processed. The script flushes the web server's buffer after each row to force updating of the displayed data. The output page generated is solely needed as an indicator of the progress of the script, which may run for 15 minutes and more in the real web application. With all browsers tested so far, up to the latest versions of Firefox 3.6, the page contents are displayed while they are being generated, row by row. FF 4.0.1 requires the page to be completely loaded to display anything. The example page above emulates this behavior, using snippets from the original code. The HTML code generated by the script has been tested to be perfectly valid HTML 4.01 Transitional.

Note that there is no point in this case in trying to speed up page display by avoiding incremental table rendering: The contents of the table rows are created at a rate of one row every other second. There is all time in the world to refresh the table display if required. Unfortunately, this new behavior of FF 4 makes it fairly unusable for applications as the one described! 

Reproducible: Always

Steps to Reproduce:
1. Run the demo page specified above with FF 4 and with any other browser (including any version of Firefox up to 3.6).



Actual Results:  
With FF 4: For about 32 seconds (the sum of the time delays intentionally set in the script) nothing happens, then the complete page is displayed.

Expected Results:  
Display the contents of the page as they are being generated (an empty table every 3 seconds, one row indicating the processing of one image file every 2 seconds).

FF 4 obviously uses some kind of heuristics to display pages containing tables either incrementally or, as above, in their entirety. For example, a page with statistics information created by the same image database is displayed incrementally although it consists of a number of HTML tables whose generation may also require significant processing time. (In this case, the script flushes the tables to the web server output only when they have really been completed and contain a significant number of rows, which may account for the difference.)

Comment 1

[Karl Riedling]

Attachment: PHP script used in the demonstration page

Comment 2

[Thomas Ahlblom]

Reproduced with:
Mozilla/5.0 (X11; Linux x86_64; rv:6.0a1) Gecko/20110509 Firefox/6.0a1

But setting html5.parser.enable to false changes that behavior to an incremental one.


This sound like a duplicate of bug 655682.

Comment 3

[Karl Riedling]

(In reply to comment #2)
> Reproduced with:
> Mozilla/5.0 (X11; Linux x86_64; rv:6.0a1) Gecko/20110509 Firefox/6.0a1
> 
> But setting html5.parser.enable to false changes that behavior to an
> incremental one.

Setting html5.parser.enable to false works all right; but doesn't that break HTML5 pages? I consider it a quick work-around, rather than a real solution.

My page specifies a DOCTYPE (HTML 4.01 Transitional) and a content type (<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">) so there is nothing to guess for the parser. On principle, the page display could start instantly. 

In fact, the current default behavior of FF4 is due to cause all kinds of problems: The output page is invoked from a form that remains on the screen for an indefinite time until the output page is finally loaded, literally inviting multiple submits. (Ok, these can be blocked with JavaScript, but that would not be necessary if the page were displayed incrementally by default.)

> This sound like a duplicate of bug 655682.

Sorry, I _did_ look through the bug reports, but I missed that!

Comment 4

[Thomas Ahlblom]

My intention was not to suggest setting html5.parser.enable to false as a permanent solution to the problem. It was more like a documented step in the fault finding and a hint in which direction to look further.

And if you disable the HTML5 parser, well then you can't see HTML5 pages. So that's not an attractive solution.

I'll make his bug a duplicate of 655682, so I suggest that you watch that one and make sure that the upcoming solution there solves your problem as well.