From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9+) Gecko/20010518 BuildID: 2001051804 Reproducible: Always Steps to Reproduce: 1. Load the URL 2. See some of the <HR>'s shrank into a got. Expected Results: <HR>'s hould have width of 100% if unspecified.

WFM, Build 2001-05-17-20, Win2k-SP1 Something that happened between the two builds?

I'm seeing this on Mac OS 9.1 as well. (Build 2001051811)

updating component

Seeing this on Linux build 2001052510. I suggest changing OS to All.

Also see bug 82768 and its testcase http://bugzilla.mozilla.org/showattachment.cgi?attach_id=36169 In bug 82768 the HR dots are observed in a div and not a table cell as with this bug. Changing to OS ALL/ALL based on comments in this bug and suggesting Mozilla0.9.2.

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

There is also a test case in http://bugzilla.mozilla.org/show_bug.cgi?id=83600.

In attachment #3 [details] [diff] [review] (which reduces attachment #2 [details] [diff] [review]), it looks like the cell's block is not reflowing the hr properly. Reassigning to waterson and moving to m0.9.3. Tbl 0117DC18 r=0 a=8940,UC c=0,0 cnt=10 Tbl 0117DC64 r=0 a=8940,UC c=8910,UC cnt=11 RowG 0117DD50 r=0 a=UC,UC c=UC,UC cnt=12 Row 0117DD8C r=0 a=UC,UC c=UC,UC cnt=13 Cell 0117DDD4 r=0 a=UC,UC c=UC,UC cnt=14 Block 0117DE30 r=0 a=UC,UC c=UC,UC cnt=15 Block 0117DE30 d=15,375 me=15 Cell 0117DDD4 d=75,435 me=75 Row 0117DD8C d=UC,435 RowG 0117DD50 d=UC,435 Initialized min=165 des=165 pref=165 Balanced min=165 des=8940 pref=165 cols=8850 RowG 0117DD50 r=2 a=8910,UC c=8910,UC cnt=16 Row 0117DD8C r=2 a=8910,UC c=8910,UC cnt=17 Cell 0117DDD4 r=2 a=8850,UC c=8790,UC cnt=18 Block 0117DE30 r=2 a=8790,UC c=8790,UC cnt=19 Block 0117DE30 d=8790,375 Cell 0117DDD4 d=8850,435 Row 0117DD8C d=8910,435 RowG 0117DD50 d=8910,435 Tbl 0117DC64 d=8940,525 Tbl 0117DC18 d=8940,525

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

-> mozilla-0.9.2. Apparently this appears on netscape.com pages.

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

Okay, so the problem is this. In the first-pass reflow, the HR frame sets its computed width to one pixel. On the second-pass reflow, the block frame decides that the HR frame doesn't need to be reflowed again, because it has no next line, and the HR frame's computed width (1px) is less than the available width. Since we'd eventually like to get rid of the HR frame altogether (see bug 38370), I'd really like to just hack the HR frame code to fix this problem. Or, fix 38370!

Which one is the less risky? :-)

hixie, dbaron: what do you think of the above atrocity? It's admittedly horrible, but it's small and simple. It basically forces the block code to reflow the line on which the HR lives because the line has a percentage-aware child. If you let me check this in, I'll promise to fix bug 38370 and dependents for mozilla-0.9.3. :-)

Seems reasonable to me. r=dbaron. (Although Ian might have some other comments.) Do other UAs behave as if there were a margin there? How big? (0.1%? 1%? 10%?) Would the real fix here (on the reflow side) be to make HRs act like a block to their parents (e.g., for line->IsBlock()) but have them internally behave somewhat like inlines? Or do we want to eventually write HR in XBL (would that be possible?)?

Ian's written <hr> with plain old CSS2. That's bug 38370. :-)

-moz-float-edge isn't plain old CSS2, but I guess it would work if -moz-float-edge works (which is questionable) :-)

I like the HR hack too. sr=attinasi (if you need it). dbaron's question is a good one: is 1% a good value to use for the margin, or would something like 0.1% be better (since it had none before)?

I'll use 0.1% (I didn't realize that we parsed decimals), which seems to work fine.

dbaron: we're within a pixel of Nav4.x and IE5 (who are each within a pixel, left or right, of each other). Although it's hard to tell exactly, it looks like on the minimal test case, we end up with... Left Right Nav 4.x 1px 0px IE5 1px 1px Mozilla 2px 1px But it's a bit tough to tell, because 4.x and IE both shade: IE shades the table, but not the HR, and 4.x shades the HR, but not the table!

a= asa@mozilla.org for checkin to the trunk. (on behalf of drivers)

Hack checked in. I'll add a regression test just to remind us about this case.

Verified on build: 2001-06-20-04-Trunk platform: Win NT The above url displays fine.

Could this fix have broken hr's for bug 88184 and bug 87543?

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

SPAM. HTML Element component deprecated, changing component to Layout. See bug 88132 for details.