Closed Bug 139152 Opened 22 years ago Closed 20 years ago

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

Categories

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

Product:
Core
Component:
Layout: Tables
Platform:
x86
All
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 77789
Milestone:
Future

People

(Reporter: Georg.Koltermann, Unassigned)

References

Details

(Keywords: testcase)

Attachments

(1 file)

This is the testcase which fails
372 bytes, text/html
Details 
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>
Just tried this with linux trunk 2002042200 and the label wraps to the next line.
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"
Changing QA Contact
QA Contact: petersen → moied
WFM with branch build ID 20020509 on winxp,
Marking WFM, Please reopen otherwise. -Thanks.
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
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 → ---

        Attachment #83331 -
        Attachment mime type: text/plain → text/html

    
    

    
  
confirmed on Linux as well.
Assignee: attinasi → karnaze
Component: Layout → HTMLTables
QA Contact: moied → amar

    
    

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

    
    

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

    
    

    
  
Bug 187899 may be related (table cells overlap if wrapped before "&nbsp;").

    
    

    
  
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
Closed: 22 years ago → 20 years ago
Resolution: --- → DUPLICATE

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: