451876 - a table with table-layout:fixed included in scrollable DIV of smaller height than the table is not displayed correctly when changing column width using javascript and style.width property.

Status: RESOLVED WORKSFORME

(Core :: Layout: Tables, defect)

Description

[johan pascal]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.1) Gecko/2008072820 Firefox/3.0.1
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.1) Gecko/2008072820 Firefox/3.0.1

Changing, by accessing the td.style.width property in javascript, the width of the header in a fixed layout table will change only the width of the modified cell and not the whole column as it should be.

The bug only happens when the table in included in a DIV element with fixed height.

It works correctly with IE6 and IE7, Firefox2.0.16(on both Linux and WinXP), Seamonkey1.1.11 but doesn't with Firefox.3.0.1(on both Linux and WinXP),Gecko/20080823021533 Minefield/3.1a2pre, Gecko/20080823000744 SeaMonkey/2.0a1pre.

Reproducible: Always

Steps to Reproduce:
1.go to the URL and follow instructions
2.Click TWICE on the top 'increase Header column 1 width by 25'. First click has a correct behavior, second click will add not needed horizontal scroll bar and change de first row td element td width only.
3.The same page contains others nearly similar table inserted in different condition(table-layout: auto; and no container DIV elements) which have correct behavior.
Actual Results:  
Note: any resizing of the firefox window after getting the incorrect display of column 1 will correct the display to have the whole column having the width of the first element.

Expected Results:  
The whole first column shall always have the same width than the first element of this column.

Comment 1

[Gérard Talbot]

Johan,

Just convert your webpage to use a strict DTD, then fix all the validation markup code and it will work in all W3C web standards compliant browsers.

http://www.gtalbot.org/BugzillaSection/Bug451876.html
tested and working as expected in Firefox 3.0.1, Internet Explorer 8 beta 1, Opera 9.52 and Safari 3.1.2 under XP. Not tested in a recent trunk build (rv: 3.1a2pre): reopen the bug report if there is a problem.

parseInt should preferably be using 2 parameters: 10 being the base. 8 is the default, not 10.
font-size:12px;
is not recommended for several reasons, one is that it disables resizing text in several browsers, 16px is the default font-size in many browsers, 12px is too small for ageing people, people with lower vision.
There may be other issues with your original webpage.

If you need help to convert your webpage to HTML 4.01 strict, then read, consult 
Using Web Standards in your Web Pages
http://developer.mozilla.org/en/Using_Web_Standards_in_your_Web_Pages

One last thing. Your bug entry was overall good. Only bug summary should be preferably under 60 characters; yours has 188 characters.

Bug writing guidelines
http://developer.mozilla.org/en/Bug_writing_guidelines

Resolving as WORSKFORME

Comment 2

[Gérard Talbot]

Mozilla Quirks Mode Behavior
"The basic table layout strategy handles widths differently in some way."
http://developer.mozilla.org/en/Mozilla_Quirks_Mode_Behavior

I also think that because the 5th column does not have a defined, specified width, then table-layout: fixed may not trigger the fixed table-layout algorithm.

Comment 3

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

Gerard -- did you mark the bug as worksforme because it actually worked for you, or because you don't like the author's authoring practices?  If the latter, please reopen.

Comment 4

[Gérard Talbot]

David, this testcase I provided
http://www.gtalbot.org/BugzillaSection/Bug451876.html
which comes from the original webpage of the reporter works for me. Same basic markup code, same CSS code, except in standards compliant rendering mode, not backward-compatible rendering mode. That's why I marked it as worksforme.

FWIW, I think table-layout: fixed has nothing to do with the problem in the webpage; it has to do with quirks versus standards mode when using automatic (not fixed) table layout.

Comment 5

[Gérard Talbot]

http://www.gtalbot.org/BugzillaSection/Bug451876.html
has been removed.

REOPENING

Comment 6

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

If we have a quirk in quirks mode that actually breaks Web pages rather than fixing them, we should remove that quirk.  Making quirks mode less quirky would be good.

Any chance you could attach the testcase you had?

Comment 7

[johan pascal]

Hi,
I'm not sure to understand everything you are talking about(quirks?) but anyway quite impressed by how fast is the reaction to a potential bug submission.

I apologize for providing not really HTML4.01 compliant code.


I don't know if it will be helpful, but you will find here:
example 1: http://johanpascal.ifrance.com/testTable_DTDHTML4.01_With_Doctype_Declaration.html
and
here
example 2: http://johanpascal.ifrance.com/testTable_DTDHTML4.01_Without_Doctype_Declaration.html

two more test cases.
I simply convert the code to be compliant with HTML4.01 strict DTD and add a column width on the fifth column header.

Unfortunally the free hosting I'm using add some ugly scripts and adverts before and after my code so I don't have online the behavior I have on my local machine(either directly browsing the file or through local apache server) which is the following:

- With the HTML4.01 strict DTD code, it actually works as expected. with FF3.01 and Gecko/20080823021533 Minefield/3.1a2pre. (example 1)

- Keeping the code unchanged but removing the doctype declaration, I have again the same strange behavior I had before. (example 2)

Browsing directly the examples on the free hosting I have the bug on both of them, probably because the doctype declaration being placed after scripts and add inserted by the hosting service it is ignored.

Comment 8

[Bernd]

Attachment: testcase from website

Comment 9

[Bernd]

Attachment: quirks mode testcase

we offer here also free hosting of test cases.....

Comment 10

[Daniel.S]

Attachment: reftests

This works for me in 3.1 beta 3 and trunk.

So here are two reftests, one for quirks mode, one for standards mode.

Comment 11

[Daniel.S]

Attachment: correct reftests

Sorry, here's the correct one.

Comment 12

[Bernd]

Comment on attachment 372207 [details] [diff] [review]
correct reftests

pushed http://hg.mozilla.org/mozilla-central/rev/e1257570fef8