User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030523 Mozilla Firebird/0.6 Build Identifier: The sidebar on http://www.democrats.org/ is extremely stretched, which makes it hard to read. Page Info says it's Standard Compliant so maybe this is Tech Evangelism Sometime it happens, sometimes not but mostly occurs during first visits without cache Reproducible: Sometimes Steps to Reproduce: 1.Go to http://www.democrats.org/ Actual Results: Sidebar is ugily stretched Expected Results: Not stretch it

*** Bug 207006 has been marked as a duplicate of this bug. ***

Am seeing the same behavior on build 2003052408. On intial load the TD for the sidebar displays at a width of nearly 800 pixels when it should load to 250 pixels. It goes to proper width when reloaded. This problem looks similar to one described in <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=153771"153771</a>.

What is the difference in the URL you changed? I can't reproduce that on the bicycle site

Looking at the source of the page referenced in <A HREF="http://bugzilla.mozilla.org/show_bug.cgi?id=153771">153771</A> I came across this : <td id=spacer class=mozside>&nbsp;</td> <!-- This is an obscene kludge. By initially having this narrow table cell, a bizarre error in Mozilla 5.0 is avoided SEE: http://bugzilla.mozilla.org/show_bug.cgi?id=153771 If anything, I would call the problem with http://www.democrats.org/ a table layout bug. After Reading the comments on bug 153771, where the reporter mentioned that the page in question loaded correctly (on first try) on a high speed connection I wonder if the same is true in this case.

I don't think it's site's problem because it works in IE High speed.... Maybe it is since cached version loads nicely...sometimes

Yeah, this is WORKSFORME using today's Win2K nightly on a broadband connection.

Do you want to ignore non high speeders? What makes IE does it right but Gecko not? Is it because IE is faster than Gecko at most pages?

I'm not saying this is invalid -- quite the opposite, if we can get a reliable way to reproduce this, it should definitely be fixed. I was just adding information to the table. When pages are loaded slowly, Mozilla renders them in chunks rather than all at once. This often exposes incremental rendering bugs that would otherwise not be seen. This is probably one of these cases.

I see this in a 5-25 Linux trunk build. I use a squid proxy so I only see it the first time I load the page. A few times, though, it's been repeatable over a reload. I suspect it's a matter of when <http://www.democrats.org/style/advanced.css> becomes available.

Ran this page through my motley collection of browsers. Displays fine on first try in IE6 and NS 4.5. On Netscape 6, on the first try, the sidebar displays a little bit wider than it should, but nowhere near as wide as it displays on Mozilla. Am going to make one last search through Bugzilla to see if I can find any other related bugs...

Ok... bug 201079 is also about the democrats.org website. Also, comments 8 and 9 of bug 149131 refer to the democrats.org website as well. Noticing that the images on the democrats.org website did not have height or width attributes, I followed the comments on bug 149131 and turned off images before loading it. The sidebar rendered properly. Turned images back on, reloaded the page, and the sidebar was oversized. So, the lack of height/width attributes for the images appear to be the issue here...

worksforme with linux trunk 20030524 pulling the site over a 56K modem, even with something else downloading in the background (site loads very slowly)...

Not for me. Attachment 124182 [details] still renders too wide the first time.

Yeah, my proposed fix didn't work for me either (sigh). But when I load it, the sidebar doesn't extend as far out as it does for the actual website. Could it be something in the JavaScript (Specifically the preloadTabs script)?

To reproduce this bug reliably enough to create a testcase, I wrote a bookmarklet called "clone slowly" that forces incremental rendering. It's on http://www.squarefree.com/bookmarklets/testbrowsers.html. Steps to reproduce reliably: 1. Load http://www.democrats.org/ or the testcase. 2. Use the "clone slowly" bookmarklet with the default setting (30) or slower.

-> Layout: Tables

*** Bug 201079 has been marked as a duplicate of this bug. ***

is this still a problem? I can't reproduce it with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a) Gecko/20030710 Mozilla Firebird/0.6 at 42kbps and before i had faster 53kbps

ignore last comment it's still Reproducible: Sometimes

I have seen this bug on democrats.org even though I have a cable modem.

Is this still an issue? I can reproduce this with the "clone slowly" bookmarklet on the testcase in Mozilla1.6, but not in Mozilla1.7, nor in the latest nightly trunk build.

Haven't seen any problem with the site for quite a while. There was discussion in some other bug report about a problem with the webpage that seems to have been fixed, I think.

marking as wfm please reopen if this is still an issue

WFM with democrats.org and with my testcase, using the "clone slowly" bookmarklet. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050405 Firefox/1.0+