Closed Bug 184104 Opened 22 years ago Closed 21 years ago

hr inside table cell loses width on certain css values

Categories

(Core :: Layout, defect, P3)

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

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Future

People

(Reporter: ve3ll, Unassigned)

References

Details

(Keywords: regression, testcase)

Attachments

(3 files, 1 obsolete file)

reporter's testcase reduced a bit
370 bytes, text/html
Details
Demonstration of bug with PRE, but without any CSS foolery
817 bytes, text/html
Details
strict testcase
992 bytes, text/html
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2.1) Gecko/20021130
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2.1) Gecko/20021130

the following html code illustrates a problem when hr element is inside
a table cell. css properties text-align and whitespace force hr to nil
removing either one will allow hr to be full width. the width property
can be used to force it but not if RELATIVE measure, ie 100px works
100% doesn't work .... very peculiar bug that occurs in all gecko products
i will not even mention that gecko uses background property and msie/opera
uses color .... that gets into the lack of standards and no clarity in the
w3 css recommendation (read politics). the width think is a BUG although
very obscure... it is for the anal retentive to find and another kindred soul
to fix ;-] ;-] ;-]  
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<title>Rule Test</title>
<style type="text/css">
hr {color:green; background:red; margin:0px; padding:0px}
th {width:130px; white-space:nowrap; text-align:left;}
</style>
</head>
<body>
<h1>Rule Test</h1>
<table summary="*">
<tr>
<th><hr></th>
</table>
<hr>
</body>
</html>

Reproducible: Always

Steps to Reproduce:
1. run the included html code
2. take out one of the offending properties (text-align|whitespace) and rerun
3. try setting hr width property with either absolute or relative measure
have fun --- simple to find, once you know where to look.
it cost me hours to find why my rules were not showing up in
sidebar navigation.
Actual Results:  
hr is reduced to dot instead of being width of table cell

Expected Results:  
view with opera arf arf    no that aint right
the rule should default to the width of the cell
minus any default boxing effect. it is a mystery why
only the intersection of these two elements cause a 
problem... and why doesnt relative work to fix ???
->Style
Assignee: asa → dbaron
Component: Browser-General → Style System
QA Contact: asa → ian
no, layout.
Assignee: dbaron → other
Component: Style System → Layout
regression between trunk builds 2002061108 and 2002061304, same as bug 154776.
probably a regression from bug 141054.

marking NEW
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression, testcase
OS: Windows 98 → All
Attached file reporter's testcase reduced a bit (obsolete) — 

    
    

    
  


  
testcase for the right bug

        Attachment #108618 -
        Attachment is obsolete: true

    
    

    
  
note to testers from original submitter
if i change doctype to strict by removing word transitional
the behaviour changes to that expected --- width of the box
so it may have something to do with quirks mode
   --- quirks mode must mean  make it quirky ;-]  ;-] ;-] 
Priority: -- → P3
Target Milestone: --- → Future

    
    

    
  


  
The same bug, but a demonstration that you don't need any CSS 
foolery to trip over it: a simple <HR> in a <PRE> in a simple 
<TABLE> will do it.

Also, a workaround: wrap the <HR> to be </PRE><HR><PRE>.

    
  

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

    
    

    
  
This will happen any time the <hr> is reflowed with an unconstrained available
width and never reflowed with a constrained available width after that....

    
    

    
  
Could this have something to do with the resize reflow optimization in the block
frame code (which I suspect is entirely bogus)?  (See
nsBlockFrame::PrepareResizeReflow and nsLineBox::ResizeReflowOptimizationDisabled.)

    
    

    
  
I just tried changing ResizeReflowOptimizationDisabled() to return PR_TRUE in
all cases and that did not help the testcases in this bug....

    
    

    
  

      
      
      
      

        Attached file
          
        strict testcase
        — 
      

    


  
wasn't hr in quirks mode a synonym for hack

    
    

    
  
Pretty much, yes...
Depends on: 60992

    
    

    
  
the way to get rid of the hack is shown in bug 38370

    
    

    
  
Patch in bug 38370 is in.  Is this still an issue?

    
    

    
  
original reporter ran his test case with today's
and the hr now spans 130 px ie. width of table cell
rather than the offending dot (assumed no width to cell)
can flag bug as repaired.  thank you for the fix

    
    

    
  
Fixed by bug 38370 
Status: NEW → RESOLVED
Closed: 21 years ago
Depends on: 38370
Resolution: --- → FIXED

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: