101013 - Major table rendering problem (Excel generated)

Status: RESOLVED WORKSFORME

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

Description

[bugs]

Just try the URL...

I think it deserves major severity because there could be the same problem with
many M$ Excel generated tables (I can't verify, don't have access to Excel
Version 10 (whatever is it)).

Comment 1

[bugs]

BTW the table renders nicely in Konqueror, well in Opera, and a bit badly in NS4.77.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Looks fine to me with a current linux build... attaching screenshot.

What is the problem exactly?  What build are you using?

Comment 3

[Boris Zbarsky [:bzbarsky]]

Attachment: screenshot

Comment 4

[bugs]

Attachment: Screenshot of incorrectly rendered page

Comment 5

[Boris Zbarsky [:bzbarsky]]

Again, what build are you using?  (I notice you did not include window
decorations in the screenshot....)

Comment 6

[bugs]

Some extra info (I tought Bugzilla recorded this, because it even displayed on
the new bug page):

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

I'm using Xfree86 4.1.0-6 packages on Debian potato, icewm, with some truetype
fonts.
When I shrink the window's size, at least the overlapping texts go away.
Konqueror (2.2) displays it almost flawlessly.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Could you please try a recent nightly?  There have been a few table fixes in the 
last 3 weeks which did not make 0.9.4....

Comment 8

[Christopher Hoess (gone)]

WORKSFORME in a fresh Linux CVS build.

Comment 9

[bugs]

This is getting more complicated. I have played with the latest nightly build
(ID:2001092121), and got interesting results:

When I load the page from the net (I have a 33.6 modem, tried with and without
other traffic), it is always displayed incorrectly, independent of font size and
encoding. (I once managed to display it correctly with an almost unreadable
small font size, and a western encoding, but can't reproduce, it could be caused
by a timing (cache?) coincidence.)

When I load the page from my disk it always gets displayed correctly (better
than NS4.77, but not as good as in Opera or Konqueror), even with larger font
sizes. Howewer if the texts don't fit in the cells, they flow out, instead of
resizing the cells, and the whole page (but this could be according to specs, I
don't know).

I'll attach the screenshots, please notice the different loading times on the
bottom.

Comment 10

[bugs]

Attachment: Incorrect (remote)

Comment 11

[bugs]

Attachment: Correct (local)

Comment 12

[Boris Zbarsky [:bzbarsky]]

setting status to new.  Sounds like we miss a reflow or something like that....

Comment 13

[anthonyd]

need a testcase for this.  i will try to track down an excel exported html 
table.  if anyone has one or can make a testcase for this, please do so and 
attach it.

thanks,
anthony

Comment 14

[basic]

seems to wfm on win32 build 2002030208 trunk

Comment 15

[bugs]

Attachment: 1st try, minor errors

Comment 16

[bugs]

Attachment: 2nd try, major errors

Comment 17

[bugs]

Screenshots created with 1.0rc1

1st: first try, looks nice with some errors
2nd: pressing enter in the url bar again, the table collapses badly

Comment 18

[Simon Montagu :smontagu]

Isn't this in the wrong component?

Comment 19

[Bernd]

reporter: please have a look at http://www.mozilla.org/newlayout/bugathon.html,
screenshots without a reduced testcase are nearly useless. Please verify that
this bug is no a dupe of bug 97205.

Comment 20

[bugs]

I would make a reduced testcase, but I don't know HTML well enough and I haven't
got Excel.
The other major issue is when I save the html, before trying to edit, Mozilla
loads and displays it (almost fully) correctly when I open the file from the
hard disk (see attachment "Correct (local)"). These make things a bit harder...

Comment 21

[Logan Ingalls]

WFM windows build 2002050806

Comment 22

[R.K.Aa.]

Is this a tables bug at all? The document type is XML.
Anyway - as per today the page in question lays out just fine.
WFM, current trunk linux.

Reporter: Can you test this again with a current build?
(Make sure to delete cache first)

Comment 23

[Igor Furlan]

nope  it does not render well on LINUX RC3.

It renders well ONLY if you select very small font (unreadable)

see attached screenshots

Comment 24

[Igor Furlan]

Attachment: it renders OK but is unreadable because of small font

Comment 25

[Igor Furlan]

Attachment: renders wrong but it is readable

Comment 26

[Igor Furlan]

MSIE is OK...  their table is wider with reasonable font size.

It seems to me, that the trick is to make table wider. I am not HTML table
specialist...  but I think that mozilla should make table wider to accomodiate
longer text lines

see the attachment

Comment 27

[Igor Furlan]

Attachment: MSIE 5.5 is OK

Comment 28

[Igor Furlan]

I think this bug is a dupe of 97205

Comment 29

[karnaze (gone)]

mass reassign to default owner

Comment 30

[chris hofmann]

http://bugzilla.mozilla.org/show_bug.cgi?id=243560 may provide the test case we
have been looking for...

Comment 31

[Bernd]

the url is 404

Comment 32

[earthsound]

The URL can be found on archive.org:

http://web.archive.org/web/20020811064423/http://www.compugroup.hu/arlista.htm

I may get a better testcase up here in a bit...

Comment 33

[Andrew Schultz]

loading the web.archive URL worksforme with linux trunk 2004121606

Comment 34

[Mats Palmgren (inactive)]

Attachment: Saving www.compugroup.hu/arlista.htm

http://web.archive.org/web/20011223091333/http://www.compugroup.hu/arlista.htm

Comment 35

[Bernd]

the testcase is wfm, winxp 20050711