226698 - Relative table width (98%) ignored -- incorrect, inconsistent size rendered

Status: VERIFIED WORKSFORME

(Core :: Layout: Tables, defect)

Description

[Alexey Spiridonov]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20030925
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 Firebird/0.7

Go to http://www.kuro5hin.org in Firebird 0.7. The main table will behave like a
fixed-width table, whereas IE and Mozilla 1.5 (as well as 1.4) render it properly. 
If you have a large screen, you may need to shrink the browser window to see the
problem. On reload, Firebird occasionally changes the table width, and a
sequence of resizes and reloads makes it behave correctly again. 
Specifically, what works for me is making the window really small, reloading,
and then making it large again.
I tried the bugs that looked similar, but couldn't reproduce any of them. 

Reproducible: Always

Steps to Reproduce:

Comment 1

[Boris Zbarsky [:bzbarsky]]

Mozilla 1.5 and Firebird 0.7 should use exactly the same layout engine.... So
it's odd that you're not seeing it in Mozilla.  Could you test a current
(tomorrow's) nightly (or 1.6b when it comes out)?  There was a change to
incremental reflow earlier today that may fix many cases like this...

Comment 2

[Alexey Spiridonov]

Err, it looks like the bug depends on a particular cache state -- I've seen it
very rarely off the machine that prompted me to log it. In particular, I did run
into it in Moz 1.5 once. I won't be able to vouch if it exists in 1.6 until I
use it on a regular basis. 

Comment 3

[Mats Palmgren (inactive)]

WFM, 2004-02-23-08 trunk Linux

Comment 4

[Jason Bassford]

->WORKSFORME

Comment 5

[Alexey Spiridonov]

I've seen this again, again on Windows. I also have some ideas on the what may
be going on. 

This time, it's the following link:
http://mozillazine.org/talkback.html?article=4824
Page validates nicely, unlike the previous link.

More often than not, I load the page, and the right sidebar remains off-screen,
requiring one to scroll. Clean-reloading and resizing, in combination, usually
make it go away.

If you load it on a slow connection, it's more clear what's going on, even if
ends up rendering it correctly. 

I see:
The main column of the table is initially sized at 100%, until the sidebar is
completely loaded. However, most of the time, the layout engine seems to forget
to figure out the right sizes at the end. It's almost as though I'd stopped the
transfer halfway through. (however, the whole page is clearly loaded, as the
footer shows up, and the stop button is off)

What I don't understand is, why does the sidebar <td> not get sized until it's
completely loaded? Performance optimization? Some servers have leaky
connections, in which case these optimizations look like layout bugs for a few
seconds at least. So, it seems that a sizing pass is getting forgotten, and if
Gecko did them more often, this wouldn't be a nuisance.

I'm again seeing this on a computer that's not mine, on which I can't set up a
debugging environment. It'd be great if someone could repro it on a more
developmentally suitable machine. If not, I'll close it again, till better times.

Comment 6

[Alexey Spiridonov]

Eck, sorry. It's Firefox 0.9rc I'm using.

Comment 7

[Bernd]

Alexey could you please retest this with a trunk current nightly (this might not
be fixed in the RC but in trunk it should)

Comment 8

[Michael Hall]

I am also seeing this problem with the above link.

Firefox 1.0pr on Linux
Gecko/20040914 Firefox/0.10.1

Comment 9

[Bernd]

marking as wfm, please reopen if you see this with a current trunk build

Comment 10

[Alexey Spiridonov]

I haven't seen this issue for a long time. Will reopen in the unlikely event it
becomes necessary.