The width of the two cells should have a ratio _around_ 1:2 It's OK both in ie4 and ns4.5, but has problems in mozilla. The extra space in the table is not distributed between the cells, but added entirely to the 2nd cell. Checked M4 and 1999042908 ----------- <table border> <tr> <td width=2000>x</td> <td width=4000>y</td> </tr> </table>

Moving to M9.

I cannot simplify the testcase any more. Duplicating as an attachment for easier viewing from the browser. Changing summary to better describe the problem.

It appears that if the widths speified are greater then the pixeld available on your minitor that it does not displayed it corectly . Im at 800x600 and did a 400 width and another 400 width and it works, I'll attach the file so you can see for yourself. Perhaps it's doing it that way as it's getting confused by the numbers being high and is only giving the first cell how much it needs to display it's contents and the second cell gets the rest of the screen width?

In 4.5 what it does is to calculate each cells width in pixels as a % of the total of each cell, notice that in the example no total width is given, so 100% is assumed which is correct. I think a fix for this would simply be if no width for the table is specified then assume 100%, and if the total pixels of each cell are more then the screen pixel width then add up to total pixels it wants and take each ones as a 100% of the total and use that as the width in 100% (if say you have three cells and 800 width available. 1 wanted 400 2 wanted 600 and 3 wanted 1000 for a total of 2000 , so for 1 400/2000 = 20% , for 2 600/2000 = 30% and for 3 1000/2000 = 50% for a total between the three of 100%. Would this be an acceptable fix?

The contest is a contest, eh? I don't actually see your point with your 400 pixel example. Change the width to 2000 in both cells in your example, and it still works. And 2000 is likely larger than your screen width. (I'm not creating a testcase for that.) Also the issue is not that simple as you say in your second comment. Cells based on their content has a minimal width, a "maximal" width, and a "specified" width (at least). (Someone might be able to correct my terminology.) If all the cell contains is text, then the minimal width is the width of the longest word, the maximal width is the length of the longest possible line of the text. I you watch how NS4.6 divides the space, you'll see that the amount each cell gets is dependent on the maximal width as well as the specified width, even if the specified width is the larger. Back to the bug, it seems to me that how it calculates currently is: give all the cells their specified width (in this case at least when its larger than the maximal width), and when it's larger than the available width (of the window), then it's trying to _substract_ an equal amount from each cell, until the resulting table fits. This way if the first width is X and the second one is Y, and X+Y is larger than the available width A then the divider between the cells end up being at A/2 - (Y-X)/2 So if X=2000 and Y=4000 as in my example, than it's trying to put the divider about 1000 pixels left from the half of the window, so the first cell ends up having its _minimal_ width. If you change X=500 and Y=1000 you can watch it behave as you resize the window. If you also change the content of the 1st cell from "x" to "x x", you'll see proof, that it gets to its minimal width, ignoring the maximal width unlike NS4.6

I see what your saying, then presumibly the correct way for it to do it in your example is to calculate A how many pixels are available in total, then to see how many are being requested by x+y, if it's too large then give the firts one the minimum it needs to display it's contents and then give the rest to y, which is as you say not correct. How about if it calculated the minimal width of each and totalled that up, if this is less then what you have available and a 100% width is requested , then take how many pixels are left and divide that amoung the total amount of cells and give the resulting amount of cells to each available one. But it would have to take into account what is being asked for in the width property of <td>, as doing it the above way would give both cells 50% even though one asks for twise what the other asks for. What would be a good way to do this? perhaps the way I sugested of adding up whats of the total of the two widths is being requested and giving each one a % of the total which is based on the % of the total it asked for. But if in doing this a cell ends up getting less then it's minimal , and other cells could stand to loose some pixels without the pixels going to them becoming less then their minimal, then an even number would be taken from other availbe cells until enough pixels become avaible to give to the cell needing extra to attain it's minimal width? This sounds very complicated though, say if you have 800 pixels and someone put's in an 800 pixel wide image in cell 1 , and in cell 2 they have some text needing minimal 8 pixels in it. the only option here would be to make the table > 100% by the minimal required to give each cell it's minimal width. Example of the above, requested 100% width (800 pixels on the persons screen), cell one guessed at 500p cell two at 300p. There is an image in cell 1 thats 800x600. It would know that 500p being asked for , for cell 1 is not enough and 300p is too much for cell 2 (or at least it's way over the min.) . then logically it would have to take from cell 2 the min amount of extra p's it needs (300p), but this leavs c#2 with 0, so it would have to extend the table beyond the screen and put in a scroll bar to give the text cell (#2) what it's m is. Would this work. is this how 4.xx does it?

I tested it in todays build under win98, and it does the same as 4.5 for the first table (since the two cells reuire more then the available width it gives each it minimum needed), but for the second one it gives using text in three cells it gives #1 and #2 their min, the #3 the rest. I still stand on that in the second table it should give the % value for each a number based on what total the three were asking for, then the % of that each one wanted (provided that giving one that % is not < the min.) if it is I guess it would need to take from one of the others that can afford to loose some pixels.

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

Don't mind me... Bug 5232, which I have just made a duplicate of this bug, has tables and nested tables with many cells with widths of 100%. Mozilla is using the CSS definition of width, and making the table wider than its specified size of 100%. The original test page from that bug is at: http://www.microsoft.com/dns/ecommerce/Starbuck.htm IE4 (and presumably NN4) render the table with a width as specified on the TABLE element, and thus do not make the page wider than the viewport.

Looks as if bug#2763 is simular to this one, same type of problem. If it's not a duplicate then I would mark it as depends on it as the effect is the same.

In 4.5 what seems to happen is that it simply uses that ratio's of what each td width was aksing for to determine what of the 100% it needs. But in 5.0 image one (which doesent show up), is given one pixel, image two is given a lot of spcae and the text at the end is given it's minimum needed, seems like instead of giving each their minimum and then giving whats left to the middle cell that it should divide what left amooung each cell. I have a sugestion to fix this bug, in the case of the pixels being requested for the <td width's=> totalling more then the avaible screen width (or less then what is being asked for), give each cell it's minimum reuired pixels to fit it's contents in (ie width of biggest image in it and/or length of longest word) then take however many pixels you have left and divide it up evenly amoung each cell. This may not be the totally correct way to interpret it but it seems like the most efficient and is worth a try if it means fixing this bug and the many that are related and/ore duplicates of it.

This bug report began with a simple, concrete statement of a problem by hyp-x. To quote troy@netscape.com on bug #5024: "This is exactly what should _not_ happen with a bug report. The original bug report has turned into several different problems." The goal is not to expand all bugs related to 'table too wide' into one omnibus bug; rather, the goal is to reduce a specific problem to a simple, reproducible testcase. Then, let the developers figure out how they want to deal with it. Specifically, csbooton has noted on other bug reports that (at least) bug #6388 and bug #3977 are duplicates of this bug. bug #6388 involves 'colgroups and relative/proportional width'; bug #3977 involves 'colspanning of replaced elements (IMG)'. The examples in this page (#5797) are single row tables that use fixed widths. Those are three distinct code paths. In the interest of improving the signal-to-noise ratio and letting Chris Karnaze spend his time on concrete problem-definitions, please stop implying that other bugs are 'duplicates' simply because they refer to a problem with table widths.

Yes, this is more unfortunate noise, but I must correct the beginning of my comments; what I had intended to say was: > This bug report began with a simple, concrete statement of a problem > by hyp-x. Now, it is a complicated listing of various comments, and > testcases that introduce other issues and elements. > > To quote troy@netscape.com on bug #5024: My apologies to hyp-x for the unintended reading of the previous comment.

Fixed width 7/28 changes.

Using 8/16 Apprunner, verified fixed