If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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




Layout: Tables
14 years ago
12 years ago


(Reporter: Alexey Spiridonov, Unassigned)


Windows 2000

Firefox Tracking Flags

(Not tracked)





14 years ago
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:
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

14 years ago
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

14 years ago
WFM, 2004-02-23-08 trunk Linux


14 years ago
Last Resolved: 14 years ago
Resolution: --- → FIXED

Comment 4

14 years ago
Resolution: FIXED → ---


14 years ago
Last Resolved: 14 years ago14 years ago
Resolution: --- → WORKSFORME

Comment 5

14 years ago
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:
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.
Resolution: WORKSFORME → ---

Comment 6

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

Comment 7

13 years ago
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

13 years ago
I am also seeing this problem with the above link.

Firefox 1.0pr on Linux
Gecko/20040914 Firefox/0.10.1

Comment 9

12 years ago
marking as wfm, please reopen if you see this with a current trunk build
Last Resolved: 14 years ago12 years ago
Resolution: --- → WORKSFORME

Comment 10

12 years ago
I haven't seen this issue for a long time. Will reopen in the unlikely event it
becomes necessary.
You need to log in before you can comment on or make changes to this bug.