Some <HR>'s shrink into a dot

VERIFIED FIXED in mozilla0.9.2

Status

()

VERIFIED FIXED
18 years ago
18 years ago

People

(Reporter: doctor__j, Assigned: waterson)

Tracking

({top100})

Trunk
mozilla0.9.2
top100
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(4 attachments)

(Reporter)

Description

18 years ago
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.
(Reporter)

Comment 1

18 years ago
Created attachment 35292 [details]
Screenshot

Comment 2

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

Comment 3

18 years ago
Created attachment 35298 [details]
testcase

Comment 4

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

Comment 5

18 years ago
updating component
Assignee: asa → clayton
Component: Browser-General → HTML Element
QA Contact: doronr → bsharma

Comment 6

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

Comment 7

18 years ago
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.
Keywords: mozilla0.9.2
OS: Windows 98 → All
Hardware: PC → All

Comment 8

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

Comment 9

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

Comment 11

18 years ago
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
Assignee: clayton → waterson
Target Milestone: --- → mozilla0.9.3
(Reporter)

Comment 12

18 years ago
*** Bug 84797 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 13

18 years ago
-> mozilla-0.9.2. Apparently this appears on netscape.com pages.
Status: NEW → ASSIGNED
Keywords: top100
Target Milestone: mozilla0.9.3 → mozilla0.9.2

Comment 14

18 years ago
*** Bug 86205 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 15

18 years ago
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

18 years ago
Which one is the less risky?  :-)
(Assignee)

Comment 17

18 years ago
Created attachment 39137 [details] [diff] [review]
force the HR frame to be percentage-aware, to trick the block code into skipping resize-reflow optimization
(Assignee)

Comment 18

18 years ago
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. :-)
(Assignee)

Updated

18 years ago
Keywords: patch
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?)?
(Assignee)

Comment 20

18 years ago
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) :-)

Comment 22

18 years ago
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)?
(Assignee)

Comment 23

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

Comment 24

18 years ago
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!

Updated

18 years ago
Blocks: 83989

Comment 25

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

Comment 26

18 years ago
Hack checked in. I'll add a regression test just to remind us about this case.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 27

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

The above url displays fine.
Status: RESOLVED → VERIFIED

Comment 28

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

Comment 29

18 years ago
*** 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.
Component: HTML Element → Layout
You need to log in before you can comment on or make changes to this bug.