81776 - Some <HR>'s shrink into a dot

Status: VERIFIED FIXED

(Core :: Layout, defect)

Description

[doctor__j]

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.

Comment 1

[doctor__j]

Attachment: Screenshot

Comment 2

[Ariel Gonzalez]

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

Comment 3

[Phil Cole]

Attachment: testcase

Comment 4

[TommyBee (No E-mail)]

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

Comment 5

[Asa Dotzler [:asa]]

updating component

Comment 6

[Marc Loiselle]

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

Comment 7

[Tim Powell]

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.

Comment 8

[lchiang]

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

Comment 9

[lchiang]

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

Comment 10

[karnaze (gone)]

Attachment: attachment #1 reduced further

Comment 11

[karnaze (gone)]

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

Comment 12

[doctor__j]

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

Comment 13

[Chris Waterson]

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

Comment 14

[Alexey Chernyak]

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

Comment 15

[Chris Waterson]

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!

Comment 16

[lchiang]

Which one is the less risky?  :-)

Comment 17

[Chris Waterson]

Attachment: force the HR frame to be percentage-aware, to trick the block code into skipping resize-reflow optimization

Comment 18

[Chris Waterson]

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. :-)

Comment 19

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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?)?

Comment 20

[Chris Waterson]

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

Comment 21

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

Comment 22

[Marc Attinasi]

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)?

Comment 23

[Chris Waterson]

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

Comment 24

[Chris Waterson]

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!

Comment 25

[Asa Dotzler [:asa]]

a= [e-mail] for checkin to the trunk.
(on behalf of drivers)

Comment 26

[Chris Waterson]

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

Comment 27

[bsharma]

Verified on
build: 2001-06-20-04-Trunk
platform: Win NT

The above url displays fine.

Comment 28

[Aaron Kaluszka]

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

Comment 29

[XenoWolf]

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

Comment 30

[Heikki Toivonen (remove -bugzilla when emailing directly)]

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