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

RESOLVED DUPLICATE of bug 107200

Status

()

Core
Layout: Tables
RESOLVED DUPLICATE of bug 107200
17 years ago
9 years ago

People

(Reporter: Miloslaw Smyk, Unassigned)

Tracking

({testcase})

Trunk
x86
All
testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(6 attachments)

(Reporter)

Description

17 years ago
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

17 years ago
Miloslaw could you create a minimized testcase demonstrating the problem. Thanks
(Reporter)

Comment 2

16 years ago
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.
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.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 4

16 years ago
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)
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
(Reporter)

Comment 5

16 years ago
Created attachment 54369 [details]
screenshot showing problems (look to the right)

Updated

16 years ago
Keywords: qawanted

Comment 6

16 years ago
Created attachment 54838 [details]
How IE 5.5 renders this

Comment 7

16 years ago
Created attachment 54839 [details]
Reduced testcase (see comments following)

Comment 8

16 years ago
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

16 years ago
 I see the problem on WIN2k too.. Changing the OS to ALL
OS: Linux → All

Comment 10

16 years ago
 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

16 years ago
Created attachment 54905 [details]
created a reduced test case of the problem

Comment 12

16 years ago
Created attachment 54958 [details]
attachment #4 [details] [diff] [review] reduced a bit further

Comment 13

16 years ago
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
Assignee: karnaze → bernd.mielke
Status: REOPENED → NEW

Comment 14

16 years ago
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

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

Comment 16

16 years ago
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

16 years ago
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

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

Comment 19

16 years ago
Created attachment 55248 [details]
should we really handle this like IE?

Updated

16 years ago
Keywords: testcase

Comment 20

16 years ago
Could you also look at bug 101013 and verify if that's a dupe or not, and also
help making a reduced testcase?
Blocks: 148109

Comment 21

16 years ago
yes  the bug 101013 is a dupe (as far as I can see)
Blocks: 101013
(Reporter)

Comment 22

16 years ago
Adding mlk keyword - mozilla is leaking around 40MB upon visiting this page.
Keywords: mlk

Comment 23

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

Comment 24

15 years ago
should we send bug 101013 and bug 148109 over to tech evangelism since
simple css fix will solve the problem?
Summary: table layout broken → (Excel-generated) table layout broken (cell overflow should default to hidden?)

Updated

13 years ago
Keywords: mlk, qawanted

Updated

10 years ago
Assignee: bernd_mozilla → nobody
QA Contact: amar → layout.tables

Updated

9 years ago
Status: NEW → RESOLVED
Last Resolved: 16 years ago9 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 107200
You need to log in before you can comment on or make changes to this bug.