63445 - tables incorrectly widened to 100% width

Status: VERIFIED FIXED

(Core :: Layout: Tables, defect)

Description

[Jonathan Baron]

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.

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: simple testcase

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Confirming bug.  The problem is that the table is getting a width of 100% when
it should shrink to fit its contents.

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

This may be related to bug 63703.

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

http://www.hcra.harvard.edu/ seems to show the same problem

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

Comment 6

[Deven Corzine]

Attachment: table width test case, with borders

Comment 7

[Deven Corzine]

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...

Comment 8

[HJ]

Ttestcase 21093 is invalid HTML.
And after cleaning your cache, you might see that it's cache related!

Comment 9

[James Green]

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?

Comment 10

[HJ]

Attachment: Just an easy way to trigger this bug

Comment 11

[HJ]

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.

Comment 12

[James Green]

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.

Comment 13

[Deven Corzine]

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...

Comment 14

[Mark Bialkowski]

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.

Comment 15

[James Green]

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

Comment 16

[Joshua Eichorn]

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

Comment 17

[karnaze (gone)]

I cannot reproduce this on WinNT.

Comment 18

[HJ]

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.

Comment 19

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 20

[Moses Lei]

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

Comment 21

[Moses Lei]

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

Comment 22

[R.K.Aa.]

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.

Comment 23

[Chris Petersen]

Yes, I'm able to reproduce this issue too. Tested with 2001010804 with Windows ME.
Attaching simple table

Comment 24

[Chris Petersen]

Attachment: A simple table with two rows and border. No alignment is specified

Comment 25

[Chris Petersen]

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

Comment 26

[karnaze (gone)]

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.  

Comment 27

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

In my Linux debug build, I can reproduce this on the first page load for all 7
testcases.

Comment 28

[Neil Fraser]

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

Comment 29

[Martin Horwath]

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).

Comment 30

[Martin Horwath]

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

Comment 31

[Martin Horwath]

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

Comment 32

[karnaze (gone)]

Marking mozilla0.8 milestone.

Comment 33

[karnaze (gone)]

Attachment: patch fixing unintialized array

Comment 34

[karnaze (gone)]

Attachment: revised patch

Comment 35

[karnaze (gone)]

The patch has been checked in.

Comment 36

[HJ]

karnaze, should that fix work in build 2001011204? because it doesn't yet!

Comment 37

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

Comment 38

[HJ]

Tnx David, was not sure about that!

Comment 39

[HJ]

After installing new build wauw, :))

Comment 40

[Martin Horwath]

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

Comment 41

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

Comment 42

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

Comment 43

[karnaze (gone)]

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

Comment 44

[Deven Corzine]

I concur that this bug is fixed; I can no longer reproduce the problem in the
2001011421 build.

Comment 45

[Diego]

I've tested all dupes with 2001011521 on linux and all seems OK.

Comment 46

[Martin Horwath]

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

Comment 47

[Val Sharp]

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

Comment 48

[Jacek Piskozub]

How many duplicates do we need for a mostfreqent bug? This one has already 11.

Comment 49

[Alex Stewart]

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

Comment 50

[Amarendra Hanumanula]

QA contact update

Comment 51

[Amarendra Hanumanula]

 Verified on build ID # 2001052213

  Marking verified