Closed Bug 87543 Opened 24 years ago Closed 24 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
(deleted), text/html
Details
0.1px margin hack in testcase for 81776
(deleted), text/html
Details
probably a better fix
(deleted), 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 (deleted) —
*** 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.
Attached patch probably a better fix (deleted) — — Splinter Review
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: 24 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: