18150 - <HR> height wrong, etc.

Status: RESOLVED FIXED

(Core :: Layout, defect, P2)

Description

[Masatoshi Kimura [:emk]]

Steps to reproduce:
1. Launch mozilla.
2. Go to the following testcase.

Actual result:
HR height is 2px shorter than they should.

Expected result:
HR height should be exactly the same as its width.

I'm using 1999110508 build mozilla.exe on WinNT4 (SP5).

Comment 1

[Masatoshi Kimura [:emk]]

Attachment: Testcase

Comment 2

[Sean Richardson]

Attachment: screen capture of testcase magnified 4x (1999110608 WinNT)

Comment 3

[Sean Richardson]

Confirmed for 1999-11-06-08-M11 nightly binary on Windows NT 4.0sp3.
Attached an enlarged  screencap of the testcase as viewed on same for easier
visibility (some of the edges are faint).

The testcase has 2 <HR>s, one defined as 1em by 1em, the other as 16px by 16px;
both display as only 14px tall. The other two cells in the testcase show
essentially the same style applied to <INPUT> and to <DIV> - both appear
correctly sized.

Comment 4

[leger]

Updating to default Layout Assignee...kipp no longer with us :-(

Comment 5

[troy]

Why are you re-reassing layout bugs? Do NOT touch layout bugs.

The bugs are assigned to Kipp so they can stay neatly organized until we have a
new owner for the block/inline code.

Comment 6

[buster]

mass moving all Kipp's pre-beta bugs to M15.  Nisheeth and I will
prioritize these and selectively move high-priority bugs into M13 and M14.

Comment 7

[Mats Palmgren (inactive)]

Adding testcase keyword. Sorry for the spam.

Comment 8

[Sean Richardson]

Adding css1 keyword -- this always was a css bug.

The <HR> elements (cells 1 and 2) are both still a bit squat, and the <INPUT>
(cell 3), sized at the same 1em by 1em as the <DIV> (cell 4) is now noticably
smaller than the <DIV>.

Tested with: 2000-01-28-08-M14 nightly binary on Windows NT 4.0sp3.

Comment 9

[buster]

mine! mine mine mine!  all mine!  whoo-hoo!

Comment 10

[rickg]

moving all buster m15 bugs to m16.

Comment 11

[buster]

bumping up priority, but moving to M17.  That means I can't get to it during 
M16, but once M17 opens it will be a high priority task.

Comment 12

[buster]

re-assigning some HR bugs to Rod.  Thanks, Rod!

Comment 13

[rods (gone)]

reassigning back to you (buster) its core layout work and it appears that most 
of these aren't HR frame issues, but are block issues

Comment 14

[buster]

mikey: notice in the test case the text control looks like it's too small.  I 
don't think this was the case with heavyweight enders.

Comment 15

[Hixie (not reading bugmail)]

Bug 38370 would probably fix this.

Comment 16

[buster]

accepted and futured, sorry for the spam

Comment 17

[Hixie (not reading bugmail)]

The HR stuff is fixed by the patch to bug 38370. The <input> is still sized
weirdly. The <div> is sized correctly.

If you want the <input> problem to be looked at, please file a separate bug.
This bug is only going to cover the <hr> case.

Comment 18

[Asa Dotzler [:asa]]

Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)

Comment 19

[Greg K.]

Confirmed using FizzillaCFM/2002070913, except that the first two HRs are taller
than they are wide. Will attach screenshot. Setting All/All.

Comment 20

[Greg K.]

Attachment: Screenshot of testcase in FizzillaCFM/2002070913

Comment 21

[Boris Zbarsky [:bzbarsky]]

The <input> behavior is purposeful (testcase is in quirks mode, after all --
testing standards in quirks mode is a bad proposition).

The <hr> behavior is fixed by the patch that landed in bug 38370.

Comment 22

[Pulsebot]

Pushed by ffxbld-merge:
https://hg.mozilla.org/releases/mozilla-beta/rev/c9eb9cf239fe
[fenix] Closes https://github.com/mozilla-mobile/fenix/issues/18150: select tabs button not displayed (https://github.com/mozilla-mobile/fenix/pull/18216)