8391 - Another problem with table cell widths

Status: VERIFIED WORKSFORME

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

Description

[cpratt]

Build ID: 1999061708
Platform: Windows NT

Content that is drawn in windows is getting the scrollbars drawn on top of it -
that shouldn't be happening. At the above URL, there is a button that says "Go"
to the right of the ZIP Code field; underneath it, there is a link that reads
"Clear". The button is clipped, and the "r" in "Clear" is (presumably)
underneath the scrollbar.

Comment 1

[Patrick C. Beard]

This is a layout problem, it's not detecting that there is extra content, and not
providing a horizontal scrollbar. There are document types where this is the
right thing to do, but not having a scrollbar is wrong.

Somehow, layout isn't measuring the correct width of this document.

Comment 2

[Hixie (not reading bugmail)]

Actually, the scroll bars are working fine, since there _is_ no more content.
The "Clear" text is being cropped by the table code, CORRECTLY, because the
cell is specifically given a width of 27 pixels, which is too short for the
whole of the word "Clear".

Mozilla is acting 100% correctly on this page, as far as I can tell.
Marking bug INVALID.

Comment 3

[cpratt]

It would seem that the problem is actually to do with table cell widths. I've
put the basic table HTML in the URL above. Here's the problem:
The page contains a single main table that is set to have a width of 618 pixels.
In this table, there are two main cells: one is 170 pixels wide and the other is
448 pixels wide. The first cell contains the ad images; the second cell contains
the form that contains the Go button and the Clear link which I mentioned in
this bug report.

The Go button is specified to be in a cell with a width of 25 pixels - but (as
you can see in the test case I've submitted) it does display correctly if the
surrounding table (the one with the WIDTH="618" is removed. I take this to mean
that 25 pixels are in fact enough for it to display correctly. Additionally,
Communicator 4.61 says that the image is exactly 25 pixels wide.

The Clear link would appear to be set to use 3 of 8 columns in a table row to
display (or 168 pixels' worth of width as the table is set to be 448 pixels
wide - I think). It as well displays correctly when the metatable is removed;
therefore, I believe that its clipping in the page is also a problem.

Comment 4

[Hixie (not reading bugmail)]

> The Go button is specified to be in a cell with a width of 25 pixels - but
> (as you can see in the test case I've submitted) it does display correctly if
> the surrounding table (the one with the WIDTH="618" is removed.

Really? When I looked at the page, I removed everything except the row
containing the GO image, the row containing the "clear" text, and the table
immediately containing those rows. The clipping still occured.


> The Clear link would appear to be set to use 3 of 8 columns in a table row to
> display (or 168 pixels' worth of width as the table is set to be 448 pixels
> wide - I think).

No -- it uses three columns, but those columns have a width of 27 pixels because
the three equivalent columns in the row above have widths of 1px, 25px and 1px
respectively.

Comment 5

[cpratt]

Attachment: Sample test case for this bug report

Comment 6

[cpratt]

Right you are about the 27 pixel cell width for the "Clear" link. However, I do
indeed see what I described as concerns the "Go" image. I've uploaded my test
case; you can obtain the missing images from
http://www.expediamaps.com/AddressFinder.asp to complete the test case.

Both Mac OS and Win32 clip the Go button when it's enclosed in the main table,
but display it correctly when it isn't. Linux displays everything correctly at
all times.

Comment 7

[karnaze (gone)]

I am not able to load all of the images on the url or the attachment. Gagan,
when you fix this please reassign to me.

Comment 8

[Gagan]

Hmmm... doesn't look like necko related. don pls. reassign. Thx.

Comment 9

[don]

Uhhh ... somebody wanna explain why this was assinged to me?

Comment 10

[karnaze (gone)]

The problem on the url appears to be fixed now. The attachment doesn't load
the images probably because it needs a <base href=..> tag.

Comment 11

[Chris Petersen]

Fixed in the Sept 27th build.