Closed Bug 87543 Opened 23 years ago Closed 23 years ago

Pages with <hr> inside <ul> inside tables rendered with extreme width

Categories

(Core :: Layout, defect, P2)

Product:
Core
Component:
Layout
Platform:
x86
Windows ME
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.3

People

(Reporter: lasse, Assigned: waterson)

References

(
URL
)

Details

(Keywords: regression, Whiteboard: pdt+)

Attachments

(3 files)

Minimal testcase
192 bytes, text/html
Details
0.1px margin hack in testcase for 81776
433 bytes, text/html
Details
probably a better fix
1.02 KB, patch
Details | Diff | Splinter Review 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:0.9.1+) Gecko/20010622
BuildID:    2001062204

Page at http://www.digitoday.no/dtno.nsf/pub/dd20010621162149_pcs_40710002
rendered with extreme width, making the page unreadable. 

I downloaded the page and cut down until all that was left was a table
containing a <ul> (have no idea what that is doing there) which contains a <hr>.
Removing any of these eliminates the bug. Will upload testcase.



Reproducible: Always
Steps to Reproduce:
1. Open URL or testcase

Actual Results:  Page renders with extreme width

Expected Results:  Should have rendered the page with about 800px width.

Bug only present in quirks mode. Disappeared when I tried to add strict doctype
in testcase.
Attached file Minimal testcase — 

    
    

    
  
*** Bug 87552 has been marked as a duplicate of this bug. ***

    
    

    
  
confirming based on the dupe...

Status: UNCONFIRMED → NEW
Ever confirmed: true

    
    

    
  
I tested this with machine at work where I have 2001060703 installed. Bug is not
present here, so this has probably regressed some time between june 7. and june 22. 

    
    

    
  
Aaron Kaluszka suggested in bug 88184 that it might me a dupe of this and that
they could be related to the fix in bug 81776. The fix was in quirk.css:
 hr {
   display: inline;
   -moz-box-sizing: border-box;
+  margin: 0 1% 0 1%; /* Mmm! Hack-on-a-hack for bug 81776 */
 }

I tried changing the line to:

 margin: 0 0.1px 0 0.1px; 

..in a local copy of quirk.css and linking it to the testcases. This fixes this
bug and bug 88184 and keeps the fix for bug 81776 intact. 
This would probably be a hack-on-a-hack-on-hack but it seems to work.. 

I have no idea how to make this into a patch. Could someone help?

    
    

    
  
Lasse, can you see if your hack fixes bug 88235 as well (ie, is it another dup?).

cc'ing watersen, who I believe wrote the patch for bug 81776.

    
    

    
  
*** Bug 88184 has been marked as a duplicate of this bug. ***

    
    

    
  
Oy: my fault. I _thought_ I needed to have percentage widths there to trick the
the block code, so I'm surprised that the 0.1px doesn't cause 81776 to re-appear?
Assignee: karnaze → waterson
Keywords: regression

    
  
Severity: normal → major
Status: NEW → ASSIGNED
Priority: -- → P2
Target Milestone: --- → mozilla0.9.3

    
    

    
  
I created a testcase with this fix applied to the testcase in bug 81176. I gave
it  a strict DTD to escape quirk.css and put the style rule for hr directly in
the document. I hope I'm correct in assuming this is a valid test. The source is:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
            "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head><style type="text/css">
 hr {
   display: inline;
   -moz-box-sizing: border-box;
   margin: 0 0.1px 0 0.1px; 
 }

</style></head>
<body>
<table width="100%" border="1">
<tr>
<td><hr></td><!-- put some whitespace space after the <hr> and it sizes
appropriately -->
</tr>
</table>
</body>
</html>

(will upload)

I tried applying the same css to the testcase in bug 88235 and it also seems to
work. In bug 88235 there also was a case of percentage values in connection with
<hr>. It seems to me that the real issue here is something with <hr> and
percentage values in the layout engine. Summary should probably be updated to
reflect that, or another bug opened?


    
    

    
  
Ok, so I went back through some of the dup's of bug 81776, and while some
worked, others didn't. (Notably, the original bugzilla URL reported in that bug
seemed to show some dottiness.)

I suspect that the reason that the 0.1px ``fixes'' the problem some of the time
is due to rounding error? Anyway, I'm going to see if I can figure out what
makes the percentage width go crazy. Failing that, I'll try to figure out (for
real) why the 0.1px works, and see if we can generalize it to make all the dups
of 81776 look okay.

    
    

    
  


  

    
    

    
  
I think that the above patch may be a better fix. When we're doing an
unconstrained reflow in the table's first-pass layout, the per span data's right
edge == NS_UNCONSTRAINEDSIZE. Doing any arithmetic with that value is silly, and
will confuse child frames that explicitly check for a containing block width of
NS_UNCONSTRAINEDSIZE (like nsHRFrame).

dbaron or rbs, could you r=? marc, could you sr=?

    
    

    
  
This is a straightforward fix that should probably go to the NS6.1 branch.
Keywords: nsBranch

    
    

    
  
sr=attinas for patch 41118 to stop doing match on symbolic constants. Good catch!

    
    

    
  
*** Bug 88235 has been marked as a duplicate of this bug. ***

    
  
Keywords: patch

    
    

    
  
r=rbs

    
    

    
  
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED

    
    

    
  
pdt+ on the assumption that this checkin is the one that also fixes bug 88766
and bug 91130.  Although this fixes those problems, are there any possible new
failures that could result?  Is there any special testing that should be done to
ensure we catch any new problems quickly?
Whiteboard: pdt+

    
    

    
  
Fix checked in on the branch. I'm pretty sure that this patch can only do good 
things: we were previously trying to do math on a value that should be treated 
only as a symbolic constant.

    
    

    
  
 The patch is already doing good things.. It works good.. Verifed on
2001-07-23-06-0.9.2
Platform: Windows ME.
Marking verified
Status: RESOLVED → VERIFIED

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: