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...
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.
WFM, 2004-02-23-08 trunk Linux
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.
Eck, sorry. It's Firefox 0.9rc I'm using.
Alexey could you please retest this with a trunk current nightly (this might not be fixed in the RC but in trunk it should)
I am also seeing this problem with the above link. Firefox 1.0pr on Linux Gecko/20040914 Firefox/0.10.1
marking as wfm, please reopen if you see this with a current trunk build
I haven't seen this issue for a long time. Will reopen in the unlikely event it becomes necessary.