table cell incorrectly computes minimum width of select input / may overflow column

RESOLVED DUPLICATE of bug 77789

Status

()

Core
Layout: Tables
P3
normal
RESOLVED DUPLICATE of bug 77789
16 years ago
13 years ago

People

(Reporter: Georg-W. Koltermann, Unassigned)

Tracking

({testcase})

Trunk
Future
x86
All
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

16 years ago
When a table cell containing a checkbox input field is set to a minimal width
(e.g. 1%) so that the browser must compute the required width,
mozilla (0.9.9) fails to consider the label text beneath the input.

The rendering is o.k. as long as both the checkbox and the label fit into
the specified table cell width. If it doesn't fit, the minimum width is
computed such that the cell only accomodates the checkbox
and the label overprints into the next column.

In the following example the rendering is ok when the first cell is assigned
a width of, e.g., 10%, but fails with, e.g., 1%.

-----------------snip------------------
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<html><head></head><body link="navy"
bgcolor="WHITE" vlink="navy">


<form name="WBS">

<table border="1" cellpadding="3" cellspacing="0" bgcolor="lightcyan">

<tr>
  <td width="1%" bgcolor="#ff80ff">
    <input value="42" name="id" type="checkbox"> 1
  </td>
  <td> 0.123 </td>
</tr>
</table></form>
</body></html>

Comment 1

16 years ago
Just tried this with linux trunk 2002042200 and the label wraps to the next line.
(Reporter)

Comment 2

16 years ago
Vadim,

after seeing your comment I just changed my testcase and added NOWRAP to the
first table cell.  Now it renders correctly, even with 1%.

So it seems that 0.9.9 computed the cell width correclty for a label that wraps
to the next line, and then forgot to actually wrap the label.

I conclude the problem is fixed in the head revision.  My workaround will be
to add NOWRAP (that's the desired behaviour anyway, and it is what Netscape
4.7 does).

Thnx for the quick reply.
Georg, can you get a newer Mozilla version and try it there? If it's also fixed
for you, mark this bug as "worksforme"

Comment 4

16 years ago
Changing QA Contact
QA Contact: petersen → moied

Comment 5

16 years ago
WFM with branch build ID 20020509 on winxp,
Marking WFM, Please reopen otherwise. -Thanks.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 6

16 years ago
Ok, so this is a little more convoluted than I thought.  The bug is still there,
thus I reopened it.

What happens is this: My application generates the first table column like this:

  <td width="1%" bgcolor="#ff80ff">
    <input value="42" name="id" type="checkbox">&nbsp;1</td>
  <td>0.123</td>

When I saved the generated HTML page in Mozilla, via "Save page as...", it saves
this code as:

  <td width="1%" bgcolor="#ff80ff">
    <input value="42" name="id" type="checkbox"> 1</td>
  <td>0.123</td>

You see that the "&nbsp;" *apparently* was converted to a space. But only
*apparently*. It is code 0240 instead of 040, i.e. a space with mark parity.

And this is what fails to render correctly.  I was mistaken to leave off the
&nbsp; in my original bug report, because I didn't recognize it when looking
at the page that Mozilla saved, the 0240 space was not visually different
from the 040 space.

I'll attach a new testcase (with the &nbsp;) so you know what must be fixed.

Thnx.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
(Reporter)

Comment 7

16 years ago
Created attachment 83331 [details]
This is the testcase which fails
Attachment #83331 - Attachment mime type: text/plain → text/html
confirmed on Linux as well.
Assignee: attinasi → karnaze
Component: Layout → HTMLTables
QA Contact: moied → amar

Comment 9

16 years ago
 Confirming on WIN2K too with branch build : 2002061708.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: testcase
OS: FreeBSD → All
Priority: -- → P3

Updated

15 years ago
Target Milestone: --- → Future

Comment 10

15 years ago
mass reassign to default owner
Assignee: karnaze → table
QA Contact: amar → madhur
Target Milestone: Future → ---

Updated

15 years ago
Target Milestone: --- → Future

Comment 11

15 years ago
Bug 187899 may be related (table cells overlap if wrapped before "&nbsp;").
Depends on: 187899

Comment 12

13 years ago
The testcase is almost identical to the one of bug 77789. In both cases the text 
doesn't cross the cell border any more.

*** This bug has been marked as a duplicate of 77789 ***
Status: NEW → RESOLVED
Last Resolved: 16 years ago13 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.