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)
401 bytes, text/html
313 bytes, text/html
1002 bytes, text/html
580 bytes, text/html
183 bytes, text/html
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
OS: Windows 2000 → All
Hardware: PC → All
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
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.
Status: NEW → ASSIGNED
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
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.
Severity: normal → minor
Priority: P3 → P4
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
Status: ASSIGNED → NEW
Comment on attachment 60033 [details] [diff] [review] patch + NS_UNCONSTRAINEDSIZE protection r=karnaze
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
Status: NEW → RESOLVED
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Seeing this on 2002010803 on Win2k SP2 as well
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
Status: REOPENED → NEW
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
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.
Status: NEW → RESOLVED
Closed: 18 years ago → 17 years ago
Resolution: --- → WORKSFORME
It got fixed by the patch in bug 38370 in case anyone cares..
Verified on Mozilla release 1.5 beta
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.