Closed Bug 60992 Opened 19 years ago Closed 17 years ago

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


(Core :: Layout, defect, minor)

Not set





(Reporter: jacob, Unassigned)



(Keywords: compat, testcase, Whiteboard: [bae:20011129] PATCH CANDIDATE_094)


(5 files, 1 obsolete file)

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
Attached file testcase
XP issue.
OS: Windows 2000 → All
Hardware: PC → All
Attached file testcase with a <div>
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.
Assignee: karnaze → buster
Component: HTMLTables → Layout
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...
QA Contact: chrisd → ian
QA Contact: ian → amar
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.
Assignee: buster → attinasi
Target Milestone: --- → mozilla0.9.1
This is only an issue in Quirks Mode. Accepting.
Summary: <hr> Draws incorrectly if it is in a cell with NOWRAP → <hr> Draws incorrectly if it is in a block with NOWRAP (Quirks Mode Only)
Moving to m0.9.2
Target Milestone: mozilla0.9.1 → mozilla0.9.2
By mandate, moving non-crashers and non-dataloss bugs out
Target Milestone: mozilla0.9.2 → mozilla1.0
Bernd found a possible relationship to Bug #88755

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
Target Milestone: mozilla1.0 → mozilla1.2
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:
that test case renders the same in NN4.77 and in hte trunk build from 20011129
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.
Severity: normal → minor
Priority: P3 → P4
Whiteboard: [bae:20011129]
Target Milestone: mozilla1.2 → Future
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.
Assignee: attinasi → bernd.mielke
Keywords: compat
Comment on attachment 60033 [details] [diff] [review]
patch + NS_UNCONSTRAINEDSIZE protection

Attachment #60033 - Flags: review+
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
Attachment #60033 - Flags: superreview+
fix + testcases checked in
Closed: 18 years ago
Resolution: --- → FIXED
Whiteboard: [bae:20011129] → [bae:20011129] PATCH CANDIDATE_094
Target Milestone: Future → mozilla0.9.7
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.
Well, would like to reopen, since it seems I can't :)

Tested on Mozilla 0.9.7 win32.
Last testcase shows problem in 2002-01-07-06 linux.  Reopening.
Resolution: FIXED → ---
Seeing this on 2002010803 on Win2k SP2 as well
Attachment #60033 - Attachment is obsolete: true
I am not going to spend any time on this hack further. We should remove the hack
and this is far beyond my capabilities.
Assignee: bernd.mielke → attinasi
Target Milestone: mozilla0.9.7 → Future
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
-> other@layout.bugs
Assignee: attinasi → other
Priority: P4 → --
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.
Closed: 18 years ago17 years ago
Resolution: --- → WORKSFORME
It got fixed by the patch in bug 38370 in case anyone cares..
Verified on Mozilla release 1.5 beta
You need to log in before you can comment on or make changes to this bug.