97205 - (Excel-generated) table layout broken (cell overflow should default to hidden?)

Status: RESOLVED DUPLICATE of bug 107200

(Core :: Layout: Tables, defect)

Description

[Miloslaw Smyk]

Linux/i386 (2001082708)

While HTML of the price list on this page was generated by Excel and is as
crappy as only a Microsoft creation can be, I still think it should not have
this kind of rendering errors like columns overflows etc.

Please take a look, but carefully - my Mozilla consumed about 200MB while
rendering and then showing source to this page.

Comment 1

[Bernd]

Miloslaw could you create a minimized testcase demonstrating the problem. Thanks

Comment 2

[Miloslaw Smyk]

Well, I'd love to, but that's the whole point - this damn MS-HTML is so complex
that I hardly have any idea where to look for problems. Also, playing with it
under Linux is extremely uncomfortable (speed).

I've tested this page under IE5 and it also made some rendering errors, albait
of smaller calibre. I can attach screenshots if necessary, but it'd be really
difficult for me to prepare a test case.

Comment 3

[Christopher Hoess (gone)]

Closing WFM, as page now seems to render acceptably, at least.  Reporter, if you
feel this bug should be reopened, please do so and attach a screenshot
highlighting the misrendering.

Comment 4

[Miloslaw Smyk]

Well, just scroll down a bit and check out the right margin. I'd not call it
"acceptable". Attaching screenshot in a moment. (2001102006/Linux)

Comment 5

[Miloslaw Smyk]

Attachment: screenshot showing problems (look to the right)

Comment 6

[Sterling Bates]

Attachment: How IE 5.5 renders this

Comment 7

[Sterling Bates]

Attachment: Reduced testcase (see comments following)

Comment 8

[Sterling Bates]

This bug actually demonstrates three issues (maybe related, maybe not).  I'm 
using build 2001102203 on Win2k on a PIII 700 w/128MB RAM.  When viewing the 
testcase, if I "jump" the scrollbar to the right quickly the last column 
(containing "zam") is rendered on top of other content.  Second, if I move the 
scrollbar relatively slowly the last column is displayed properly, and the 
computer description column is properly truncated, but when viewing the 
original URL (didn't include in my testcase, sorry) the second-last column has 
a character that gets rendered on top in both cases.  (I think those two might 
even be dupes.)

The third problem is that IE properly displays an up or down arrow in the 
second-last column, while Mozilla displays an incorrect value.  This may be due 
to i18n font rendering but I don't know.

I recommend OS->All

Comment 9

[Amarendra Hanumanula]

 I see the problem on WIN2k too.. Changing the OS to ALL

Comment 10

[Amarendra Hanumanula]

 I think the problem is with the style that the MS Excel used to create this 
page. I will attach the reduced test case..

Comment 11

[Amarendra Hanumanula]

Attachment: created a reduced test case of the problem

Comment 12

[karnaze (gone)]

Attachment: attachment #4 reduced a bit further

Comment 13

[Bernd]

it looks pretty much like we have problems if availableWidth < min content width
in the table cell. A fixed table layout bug -> steeling the bug

Comment 14

[karnaze (gone)]

Bernd, one problem is the way we are handling nowrap in the block. The cell 
block should not be forcing a larger max element size than the table can easily 
accomodate. I think alexsavulov and I need to get together and resolve the 
issue. 

Comment 15

[karnaze (gone)]

Even without fixed-layout, we are letting the nowrap override the width on the 
table, unlike IE.

Comment 16

[Alexandru Savulov]

there is a bug 100604 that has a similar issue for tabble cells.

Yes, we prioritize "nowrap" if specified in <style> whereas IE and NAV
prioritize WIDTH no matter where it occurs.

Looks like this issue needs a general solution that covers all the elements
affected.

Comment 17

[Bernd]

Chris, I am a little bit scared by your and Alexandru's comment, if you both
work out a solution please let me review this, the nowrap text should overflow
cells in table-layout:fixed as long as there is no overflow:hidden. 

Comment 18

[karnaze (gone)]

Bernd, I'm more concerned about quirks mode behavior (ie IE). For that, there is 
probably no overflowing of cells.

Comment 19

[Bernd]

Attachment: should we really handle this like IE?

Comment 20

[bugs]

Could you also look at bug 101013 and verify if that's a dupe or not, and also
help making a reduced testcase?

Comment 21

[Igor Furlan]

yes  the bug 101013 is a dupe (as far as I can see)

Comment 22

[Miloslaw Smyk]

Adding mlk keyword - mozilla is leaking around 40MB upon visiting this page.

Comment 23

[Amarendra Hanumanula]

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

Comment 24

[Daniel Wang]

should we send bug 101013 and bug 148109 over to tech evangelism since
simple css fix will solve the problem?