169170 - tables fail to render when streamed *very* slowly

Status: RESOLVED WORKSFORME

(Core :: Networking: HTTP, defect)

Description

[Edgar]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826

ok. This is a weird one.

I use ASPX to create a rather large asp:datagrid which outputs a table. The
table is formated using Stylesheets and uses a fixed table-layout. The whole
page validates more or less as html 4.01 strict (more or less means that aspx
insists on giving the form a name-attribute).

Now while the rendered table is completly f***ed up, whenever I "Save Page As"
and load the saved version - everything is ok.

The bug further depends on the output-caching setting of ASPX. With
output-caching enabled the table renders ok. Disabeling output-caching triggers
the bug.

It get's weirder though:

I tried to produce a testcase - took the saved html-file, uploaded it to a unix
machine, renamed it to .php, turned output caching off and inserted a couple of
flush() instructions to make sure the table arrives "in pieces". However the bug
was not triggerd.

I took the saved html-file, renamed it to .aspx, added a couple of server-sided
controls but left the table as cleartext. Again the bug was not triggerd.

Note that the aspx-engine ran on the same machine as Mozilla in all tested cases
which triggerd the bug. I havn't yet been able to test it over the network.

I suspect it could have something to do with setting or not setting of the http
Content-Lenght headder (it's independed of http1.0 vs http1.1). Or it could be a
Windows issue with the processes (aspnet_pw.exe, inetinfo.exe and mozilla.exe)
switching back and forth.

One more hint: Often (but not always) the bug is not triggerd the first time the
page is displayed. I know of no conclusions to draw from that fact though.

If anybody is interested in the app that produces the table, I can mail it.

Reproducible: Always

Steps to Reproduce:

Comment 1

[Darin Fisher]

reporter: can you please enable some mozilla logging?

  set NSPR_LOG_MODULES=nsHttp:5
  set NSPR_LOG_FILE=c:\http.log

set these in a DOS console, and then run mozilla from within that console.  then
just upload c:\http.log to this bug report.  it might tell us something about
what you're seeing.  thx!

Comment 2

[Edgar]

Attachment: http.log as requested, screenshots and html-source

http.log - 4 Transactions: I loaded the page (1x Main.aspx, 1x Main.css), chose
"Testkonto 2" - the table rendered well (1x Main.aspx), pressed reload - the
table rendered bad (1x Main.aspx)

Main.aspx.html - The saved page (I edited it a bit to hide customer info). 

bad.png - A screenshot of a bad atempt

good.png - How it is supposed to look

-----

One more comment: I discovered, that when the page is opened in DOM-Inspector,
the computed width-attributes of the <td>s and <col>s are different for good
render attempts and bad ones. So it might not be a http-issue after all.

Comment 3

[Michael Lefevre]

reporter (edgar): can you reproduce this bug with a recent build of mozilla (for
example, 1.2.1)? if so, please comment again with details. if not, please
resolve this bug as WORKSFORME. thanks.

Comment 4

[Michael Lefevre]

No response from reporter for >30 days. resolving WORKSFORME.

Reporter: If you can reproduce this with a recent build of Mozilla, then please
reopen this bug and give details. Thanks.