198623 - dynamic segment feature (hide/show) keeps on expanding width of a 3-column table-based liquid layout

Status: RESOLVED DUPLICATE of bug 186593

(Core :: Layout: Block and Inline, defect)

Description

[Michael Guitton]

User-Agent:       Mozilla/4.0 (compatible; MSIE 5.22; Mac_PowerPC)
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.2) Gecko/20030106

At http://64.226.40.113/, you'll find a 3-column table-base liquid layout (left 
and right column have a fixed size. Center column is expected to fill the 
available space. Mozilla renders it perfectly. However it doesn't behave as 
expected when you click on '1 | 2 | 3 | 4' hyperlinks navigation at the bottom 
of the 2nd column. Those links expand/collapse <div>-enclosed content 
by manipulating the display property (switch from 'block' to 'none', and vice 
versa).  The problem lies with the fact that 2nd column width keeps on 
growing (ruining the intended effect). Problem is triggered when such 
content is enclosed within a table cell.

Reproducible: Sometimes

Steps to Reproduce:
1. click repeatively on the 1 | 2 | 3 | 4 links (sometimes it triggers 
immediately, sometimes it requires more clicks -- perhaps it depends on 
the actual width of the browser window)
2. after a few segment collapsings, the global content width increases 
each time you toggle the "visibility" of an element

Actual Results:  
Enclosing table width keeps on growing (!?)

Expected Results:  
The same as Internet Explorer 5.x for Mac OS 9 or X:
reveal the hidden segment within the center column and not expand width 
of enclosing table...

Comment 1

[Michael Guitton]

I nearly forgot. Bug does not trigger within Netscape 6 for Mac OS 9

Comment 2

[Michael Guitton]

I found a work-around. At the bottom of each cell of the 3-column table 
template, I had placed a spacer GIF (I know, that's an awful design trick;) 
that assigns a min-width to each column (until CSS support of this 
property is unified among all browsers and platforms). I moved those 
spacer GIFs before actual content is inserted in the cell and voila no more 
hideous bug! You can try the following URL and compare the two different 
behaviors:

http://64.226.40.113/nobug.php

Comment 3

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

You're using a very old build.

*** This bug has been marked as a duplicate of 186593 ***

Comment 4

[Michael Guitton]

So the problem is tied with floaters... Interesting. However my work-
around is till applicable for older Mozilla versions.

What do you mean by using a very old build? This the latest camino 
available. I also downloaded Mozilla 1.0.2 and could trigger the same 
layout bug. What build should I try?