60992 - <hr> Draws incorrectly if it is in a block with NOWRAP (Quirks Mode Only)

Status: VERIFIED WORKSFORME

(Core :: Layout, defect)

Description

[Jacob Steenhagen]

I'm not 100% certain that this bug belongs in HTMLTables, but it's seems like
the logical place for it to start.

If a horzontal rule is placed inside of a table cell that has the NOWRAP
parameter (<td nowrap>) then it only seems to draw a very small portions of the
widget.  If you specify a width (# of pixels, not %) then it does draw the
correct width, but it right justifies it.

Noticed this bug with a CVS build from 11/21 on Win2k

Comment 1

[Jacob Steenhagen]

Attachment: testcase

Comment 2

[Henri Sivonen (:hsivonen) (not reading bugmail until 2025-02-06)]

XP issue.

Comment 3

[Bernd]

Attachment: testcase with a <div>

Comment 4

[Bernd]

the <hr> seems to be confused by the nowrap attribute. IE5 and NN4.7 handle both
cases with the div identical , mozilla should do the same. Before digging into
table stuff the hr behaviour has to be fixed in div's. Over to Steve.

Comment 5

[Hixie (not reading bugmail)]

Netscape's standard compliance QA team reorganised itself once again, so taking 
remaining non-tables style bugs. Sorry about the spam. I tried to get this done 
directly at the database level, but apparently that is "not easy because of the 
shadow db", "plus it screws up the audit trail", so no can do...

Comment 6

[karnaze (gone)]

Moving to m0.9.1 and reassigning to attinasi. We need to deal with nowrap in the 
block code and remove the hacks in table code.

Comment 7

[Marc Attinasi]

This is only an issue in Quirks Mode. Accepting.

Comment 8

[karnaze (gone)]

Moving to m0.9.2

Comment 9

[Marc Attinasi]

By mandate, moving non-crashers and non-dataloss bugs out

Comment 10

[Markus Gerstel]

Bernd found a possible relationship to Bug #88755

Comment 11

[basic]

Attachment: testcase with a button that causes the colour/background colour to change

Comment 12

[basic]

I've just created an testcase that is almost identical to the first one except
that it contains a button which will cause the background colour and text colour
to change when clicked. The bug seems to go away after the button is clicked.

Also in the first testcase if the window is resized the bug goes away too.

this was tested with win32 nightly trunk build ID 2001092803

Comment 13

[rubydoo123]

I'm not sure what the button issue has to do with the HR not drawing correctly, 
if that is an issue than please open a new bug about that speciifc issue.

As for the HR issue:
http://bugzilla.mozilla.org/attachment.cgi?id=19626&action=view
that test case renders the same in NN4.77 and in hte trunk build from 20011129

http://bugzilla.mozilla.org/attachment.cgi?id=22359&action=view
the top div does not render the same in NN4.77 and the trunk build
in the example, a div with whitespace : nowrap is set and the HR flows across 
the entire window.

Comment 14

[Bernd]

Marc, I guess you can live with it when I steal the bug. The issue here is that
in quirks.css hr is defined as display:inline (see bug 18754 for the nasty
details), so when displaying hr's in quirks mode they take part in the line
layout. As part of the linelayout the get exposed to the nowrap mechanism, which
gives as a available width the screen width.

Comment 15

[Bernd]

Attachment: patch + NS_UNCONSTRAINEDSIZE protection

Comment 16

[karnaze (gone)]

Comment on attachment 60033 [details] [diff] [review]
patch + NS_UNCONSTRAINEDSIZE protection

r=karnaze

Comment 17

[Marc Attinasi]

Comment on attachment 60033 [details] [diff] [review]
patch + NS_UNCONSTRAINEDSIZE protection

lovely ;)  Someday we have to fix the HR in quirks mode, it is such a hack.
Patch looks nice though, sr=attinasi

Comment 18

[Bernd]

fix + testcases checked in

Comment 19

[Andrea]

Attachment: This html file shows how an <hr> tag inside a <font> one still won't work

Reopening this bug for the quirks mode.
The <hr> tag won't work inside a <font> one, uder the conditions previously
described in this bug.

Comment 20

[Andrea]

Well, would like to reopen, since it seems I can't :)

Tested on Mozilla 0.9.7 win32.

Comment 21

[Boris Zbarsky [:bzbarsky]]

Last testcase shows problem in 2002-01-07-06 linux.  Reopening.

Comment 22

[Scott Tran (Wildcard)]

Seeing this on 2002010803 on Win2k SP2 as well

Comment 23

[Bernd]

I am not going to spend any time on this hack further. We should remove the hack
and this is far beyond my capabilities.

Comment 24

[kitchin]

Attachment: <hr> also bad inside <pre> tag in table cell.

Comment 25

[kitchin]

You can temporarily fix the appearance by using View/Increase Text Size and then
Decrease Text Size.
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4a) Gecko/20030316 Phoenix/0.5

Comment 26

[Adam Hauner]

-> [e-mail]

Comment 27

[Bruce Davidson]

Right, I hope I'm don't end up having to extract my foot from my mouth - but
this appears to have been fixed (possibly quite recently). I can't put my finger
on the fix in Bonsai but I've looked at all the testcases under bug 154776, bug
82333 and bug 60922. All the test cases work in recent Camino (2003081002) and
the latest Mozilla 1.5b dev (2003081303). In particular the <hr> elements on ftp
sites / Apache index pages all work.

Marking all 3 of these bugs as WFM.

Comment 28

[Boris Zbarsky [:bzbarsky]]

It got fixed by the patch in bug 38370 in case anyone cares..

Comment 29

[Andrea]

Verified on Mozilla release 1.5 beta