94449 - left column is too wide

Status: RESOLVED WORKSFORME

(Core :: Layout: Tables, defect, P3)

Description

[Igor Furlan]

left part of the two coloumn table uses 50% of the window size instead 15-20%

MSIE, Opera5.0,NS4.77 show the page OK

my system:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010628

Comment 1

[Igor Furlan]

Attachment: left is NS4.77 right is mozilla .. there is a big difference in tables

Comment 2

[Mats Palmgren (inactive)]

Attachment: Testcase #1

Comment 3

[Bernd]

how many bugs can be in a single File ???? (BasicTableLayoutStrategy.cpp)

Comment 4

[Bernd]

The bug has gone WinNT 2001082109. But they have some very strange layer
handling in navcond.js. So before marking this as wfm sending it over to evangelism

Comment 5

[Michael Kaufmann]

This bug still exists. I've made a new testcase (see below).

Comment 6

[Michael Kaufmann]

Attachment: Testcase #2 (New testcase)

Comment 7

[Michael Kaufmann]

Bernd Mielke: I've added you to the CC: list. Could you have a look at the new 
testcase and set the component back to layout?

Comment 8

[Bernd]

taking back

Comment 9

[Bernd]

Attachment: patch

Comment 10

[Bernd]

the patch changes the allocation mode from min content based calculation to a
calculation that looks for the biggest spec. for the corresponding column

Comment 11

[Michael Kaufmann]

I've made my first own mozilla build and tried the patch. In the new testcase,
the second and the third table are rendered better - the first column is
smaller, but still not as small as it should be. The rendering of the first
table hasn't changed.

The second testcase should be rendered as following:

First and second table: The first column should be as small as possible
Third table: The first column should have a width of 50 pixels

I hope Bernd can look at this once again.

Comment 12

[Michael Kaufmann]

Attachment: Reference rendering of the new testcase (using Opera)

Comment 13

[Igor Furlan]

As far as I see ...  the bug is eradicated from mozilla.
At least with the test case http://www.ultraedit.com/

So, I am changing this bug to FIXED.

I am using the version 0.9.4  for Linux RH6.2 
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20010913

Thank you guys for your great work

Igor

Comment 14

[Michael Kaufmann]

This bug is NOT FIXED at all - I see it with the URL and the new testcase.
(Mozilla 0.9.4 on Windows). Perhaps you only tested with a screen resolution of
640x480 - use at least 800x600 or 1024x768 to reproduce the bug (or take the new
testcase).

This bug must be reopened and the keywords "patch" and "review" must be removed
because we need a new patch. 

Comment 15

[Michael Kaufmann]

Removing the "patch" and "review" keywords. (See last comment)

Comment 16

[Igor Furlan]

Just for the record. I have tested http://www.ultraedit.com/
on my LINUX box with the 21 inch screen and resolution 1200x1600.

I do not see any problem. The page is rendered correctly...

Yes,  you are right .. I did not check/test with the NEW test case

Comment 17

[Igor Furlan]

Attachment: Ultraedit.com with Mozilla 0.9.4 on Linux (1600x1200)

Comment 18

[Michael Kaufmann]

That's strange. The window in your screenshot has a width of 1600 pixels, but 
the content in the window has a width of only 640 pixels.

Comment 19

[Michael Kaufmann]

Attachment: Ultraedit.com with Mozilla 0.9.4 on Windows 98 SE (1600x1200)

Comment 20

[Igor Furlan]

Michael Kaufmann said:

That's strange. The window in your screenshot has a width of 1600 pixels, but 
the content in the window has a width of only 640 pixels.

Igor:
Yes, you are right. I think that Mozilla 0.9.4 on LINUX renders the page
correctly. It seems that WINDOWS build still contains the bug. So,
the bug is resolved (fixed) only partialy :(((

This bug should remain REOPENED !!

Comment 21

[Igor Furlan]

I tried the test case  
http://bugzilla.mozilla.org/attachment.cgi?id=47146&action=view 

on Mozilla 0.94.

Yes, I can confirm your statement. Mozilla does not know what to do
with  tables. "ultraedit" site is OK...  but test case is definitely NOT

Comment 22

[Michael Kaufmann]

http://www.ultraedit.com is really rendered differently on Windows and Linux.
The windows version of Mozilla stretches the table to the whole window width,
the Linux version doesn't stretch the table. Does anybody know why this happens?

Comment 23

[Bernd]

Michael, can you see the difference between linux and windows also with the
testcase???

Comment 24

[Michael Kaufmann]

No, the testcase looks identically on both platforms.

Comment 25

[Michael Kaufmann]

I've made a page which looks differently on Linux and Windows. It took me much 
time, but the result is surprising.

- On Windows, the yellow cell is stretched, on Linux not.
- On Windows, the text on the left doesn't wrap if you make the window smaller, 
but on Linux it does.

If you change only a little bit of the page, I'll bet that it looks identically 
again on both platforms. This happens if you

- replace the text "When was UltraEdit There?" with some shorter text
- remove the FONT FACE tag (even if you remove only the SIZE attribute). It's 
very important that the font "Verdana" doesn't exist on Linux. If you replace 
FACE="Verdana, Arial, Helvetica" with FACE="ThisFontDoesntExist", the Windows 
version of Mozilla displays the page like the Linux version.

Most other browsers display the page like the windows version.

Comment 26

[Michael Kaufmann]

Attachment: Testcase #3 (looks differently on Linux and Windows)

Comment 27

[Michael Kaufmann]

Ignore the point that the text wraps on Linux but not on Windows. On Linux, the
text above is shorter, on Windows not. So the only issue is that the yellow cell
isn't stretched on Linux.

Comment 28

[Michael Kaufmann]

Attachment: Testcase #4

Comment 29

[Michael Kaufmann]

I've created an even simpler testcase. It shows the problem much clearer than
attachment 50412 [details] (Page that looks differently on Linux and Windows).

If a patch fixed testcase #2 (attachment 47146 [details]) and this new testcase #4
(attachment 50454 [details]), it would fix Ultraedit.com too.

Comment 30

[Bernd]

I don't get the idea of testcase #4, how it should be rendered and why it should
rendered like this. For me this issue looks like, that here two specifications
clash 100px width for the cell and 100% width for the table. Then the question
arises how the additional space should be distributed, the distribution in
mozilla is based on min content width. If somebody would like to maintain one
should use 100* 1* 100* notation.

Comment 31

[Bernd]

Attachment: testcase with 100*

Comment 32

[Michael Kaufmann]

I think the distribution of the additional space should be changed.

First, give all cells enough space that their content fits into the cell.
Second, if still some space is left, distribute it to ALL the cells, not only to
those who have grown in the first step.

Mozilla does only the first thing, Netscape 4.x also does the second. The second
is important: If the text fits into a cell in one operating system but doesn't
fit on another (because the font is different, like it is the case with
attachment 50412 [details]), the page is looking completely different because once the
text is larger than the specified cell width (it could only be 1 pixel larger)
it has the "privilege" to grow infinitely, but other cells just stay small.

I'll attach another testcase. There, you can see that it works if the WIDTH is
specified on all cells. It works too if the middle column has a width of 3
instead of 1 pixel. (Does this mean that an empty cell has a minimal width of 3
pixels, else it has to grow?)

Comment 33

[Michael Kaufmann]

Attachment: Testcase #6

Comment 34

[Igor Furlan]

Linux kernel 2.2.15-5 (RH6.2) running mozilla 0.9.5 shows
the same problem as mozilla 0.9.4 .. in other words, bug is still here 

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011012

Comment 35

[Igor Furlan]

This test case is still not rendered correctly

http://bugzilla.mozilla.org/attachment.cgi?id=47146&action=view 


Mozilla 0.9.6
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.6) Gecko/20011120

Comment 36

[Boris Zbarsky [:bzbarsky]]

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

Comment 37

[Michael Kaufmann]

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

Comment 38

[Michael Kaufmann]

From bug 146583:

If you change the DOCTYPE to strict using the following:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">

then Mozilla 1.1 renders the pages in strict (standards compliant) mode. Adding
this doctype to the testcases #4 and #6 makes them look allright.
The testcase #2 and the original page ( http://www.ultraedit.com ) also look
better in standards mode, but still not like they look in other browsers. It
could be that Mozilla does it right and all other browsers do it wrong.

Can someone confirm that the way Mozilla renders the testcase #2 in standards
mode is "the right way"?

Usually pages look the same as in other browsers if the non standards compliant
mode (Quirks) is used. I think we should improve the Quirks mode here.

Comment 39

[Michael Kaufmann]

I forgot to say that the following DOCTYPE triggers the standards mode too (and
can be used in old HTML files):

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">

Comment 40

[Michael Kaufmann]

Attachment: Testcase #2 with new DOCTYPE

Comment 41

[karnaze (gone)]

mass reassign to default owner

Comment 42

[Michael Kaufmann]

With Mozilla 1.7 final, all test cases look OK, except testcase 2. Internet
Explorer and Opera render it differently. But it's difficult to say which
rendering is correct and which not, because the table HTML code contains
contradictions (the whole table size is "100%", but every column has a fixed
pixel size).

I suggest that we close this bug.

Comment 43

[Michael Kaufmann]

Closing this bug.