Closed Bug 63445 Opened 25 years ago Closed 25 years ago

tables incorrectly widened to 100% width

Categories

(Core :: Layout: Tables, defect)

Product:
Core
Component:
Layout: Tables
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.8

People

(Reporter: jonathanbaron7, Assigned: karnaze)

References

(
URL
)

Details

(Keywords: regression)

Attachments

(6 files)

simple testcase
81 bytes, text/html
Details
table width test case, with borders
329 bytes, text/html
Details
Just an easy way to trigger this bug
1.05 KB, text/html
Details
A simple table with two rows and border. No alignment is specified
302 bytes, text/html
Details
patch fixing unintialized array
1.53 KB, patch
Details | Diff | Splinter Review
revised patch
1.68 KB, patch
Details | Diff | Splinter Review
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-3 i686; en-US; m18) Gecko/20001220 BuildID: 2000122008 In a two-column table, with <center> around the whole table, the left column is on the left edge of the screen. This can be done and undone by changing the size of the window by dragging the lower right corner. I can't find a pattern. Reproducible: Always although not at all sizes Steps to Reproduce: Load the page and change the size of the window. Watch the left column of text. The size change on the bottom works. I'm not sure about the right. Actual Results: Left column is either flush left or properly centered, depending on the shape of the window. Expected Results: Centered all the time. Started 12/19. The page has two separate tables, and they both have the problem.
Confirming bug. The problem is that the table is getting a width of 100% when it should shrink to fit its contents.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: mozilla0.8, regression
Summary: center doesn't work for left column of table → tables incorrectly widened to 100% width
*** Bug 63734 has been marked as a duplicate of this bug. ***
This does appear to be a race condition, because I can only reproduce the bug intermittently; bug 63703 sounds relevant. The test case I attached was deliberately made a little more complex (font changes, hyperlinks) than the simplest case, because it seems to show the bug more often. Every time the table reflows, from the initial load or resizing the window (even just vertically), there's a chance that the table will become 100% of the window instead of centering the table with its expected width. Other times, it will format correctly. If this is a race condition, as it appears to be, it may be easier or harder to reproduce on faster or slower machines -- anyone who can't reproduce this should keep that in mind. I first noticed this problem because the Google home page (http://www.google.com/) was suddenly getting formatted differently on newer builds. Investigating the problem, I determined it was a problem with the HTML table sizing, and that it was intermittent. I have NOT been able to reproduce this problem in the 2000121821 build (or earlier builds I've also tested), but it's been reproducible in every build I've tried starting with 2000122008. Something changed between 2000121821 and 2000122008 that either introduced this bug, or made it much more visible. Hopefully it's just a change in the HTML table code, but (being a probable race condition) it could be something else entirely...
Ttestcase 21093 is invalid HTML. And after cleaning your cache, you might see that it's cache related!
OK based on the dates Deven's given, the following bugs got fixed that *may* have triggered something: bug 47163, bug 60807, "and others", which cover BasicTableLayoutStrategy when colspans are used. H-J: care to clarify exactly what you meant wrt to cache issues?
Sorry guys but first it looked like a cache problem, because when I cleaned up my cache, the problem was solved. But after a while, there it was again. I took some code from our website and made a testcase of it. If you hover your mouse over the table, it sometimes resizes to 100%! So now you don't have to reload over and over again. I hope this will help people to track this bug.
Yep, I just downloaded the index page of mozilla.org, and used HTML Tidy to make an XHTML version of it. It seems to display fine, until you hover over various areas of tables which cause reflows as seen in this latest attachment by H-J.
Anything that can cause a reflow of the table seems able to trigger the bug. Reloading the same page over and over is one approach, but I had pretty good luck with just using opaque resizing to cause lots of reflows...
I think http://tribble.dyndns.org/stats is a real-world example of this bug. The HTML doesn't seem to be broken, and the page does occasionally load correctly.
*** Bug 64069 has been marked as a duplicate of this bug. ***
Build 2001010108 I've been seeing this bug all over the place www.yahoo.com (being a good realworld example) Seems that any page that uses centerd tables has this problem
I cannot reproduce this on WinNT.
Keywords: qawanted
Karnaze, I'm using build 2001010708 on WinNT4 Sp6b and it's not fixed, at least on my systems it's still the same problem. You need to look at the right part of your screen, when you need my testcase! You may trigger this bug sometimes, but not always, at least I can't do that.
The first of the 3 attached testcases (the one I wrote) doesn't seem to trigger the bug anymore. It's probably an incremental reflow bug, so it won't always happen even on the testcases that do show it. Keep trying.
*** Bug 64701 has been marked as a duplicate of this bug. ***
I still see this bug 80% of the time on all testcases, including the one from 12/20 from dbaron and the one from my dup at: http://bugzilla.mozilla.org/showattachment.cgi?attach_id=22109 Anyone have any idea what's causing this yet? Linux 2001010516
a page that shows too wide table now (100%) is http://counter.li.org/reports/this-month.html It is a simple page and used to look like in NC4*. No width is specified and there is only one table.
Yes, I'm able to reproduce this issue too. Tested with 2001010804 with Windows ME. Attaching simple table
Chris K asked me to attach the above test and list specfic steps to reproduce: 1) Load simple table test in N6 2) Table should appear in correct size. Now maximize window so that it is the size of monitor. Press the reload button. 3) Table width should increase to the width of the page. If not, resize the width of the window and reload the page again. 4) From what I'm able to see, the bug happens after resizing the window multiple time and reloading the page
Has anybody reproduced this bug using a debug WinNT build (or any debug build)? I watched Chris Petersen reproduced it (with his test case) on his optimized build, but I still have not been able to reproduce it on a debug build.
In my Linux debug build, I can reproduce this on the first page load for all 7 testcases.
*** Bug 64875 has been marked as a duplicate of this bug. ***
i can reproduce this bug with http://bugzilla.mozilla.org/showattachment.cgi?attach_id=22193 (last testcase) on win 98 with buildid 2001010920. the only thing you have to do is, move the mouse over the hover links. you'll notice that the table gets sometime 100 % in width(i needed 15 seconds).
for my last comment use :http://bugzilla.mozilla.org/showattachment.cgi?attach_id=21453 i think i found a better way to reproduce this bug on windows: tested with buildid 2001011020 on win98 - screen resolution 1152x864 window maximized. 1. load http://www.rtvslo.si/html/radio-slo/index.html 2. load http://bugzilla.mozilla.org/showattachment.cgi?attach_id=22193 3. load http://www.mozilla.org 4. then use the back and forward buttons in one of five cases the testcase table gets 100% in width. the first url in this discription is from an other bugreport with a similar behavior. OS should be changed to ALL
*** Bug 64876 has been marked as a duplicate of this bug. ***
Marking mozilla0.8 milestone.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.8
Attached patch revised patch — — Splinter Review
The patch has been checked in.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
karnaze, should that fix work in build 2001011204? because it doesn't yet!
No. Considering it was checked in on 2001-01-12 at 16:26 PST, the first build it should appear in is 2001-01-12-21
Tnx David, was not sure about that!
After installing new build wauw, :))
*** Bug 64878 has been marked as a duplicate of this bug. ***
*** Bug 64342 has been marked as a duplicate of this bug. ***
*** Bug 64087 has been marked as a duplicate of this bug. ***
*** Bug 65143 has been marked as a duplicate of this bug. ***
I concur that this bug is fixed; I can no longer reproduce the problem in the 2001011421 build.
I've tested all dupes with 2001011521 on linux and all seems OK.
*** Bug 65559 has been marked as a duplicate of this bug. ***
*** Bug 66089 has been marked as a duplicate of this bug. ***
How many duplicates do we need for a mostfreqent bug? This one has already 11.
*** Bug 65999 has been marked as a duplicate of this bug. ***
Keywords: mozilla0.8
QA contact update
QA Contact: chrisd → amar
Verified on build ID # 2001052213 Marking verified
Status: RESOLVED → VERIFIED
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: