Closed Bug 24770 Opened 20 years ago Closed 20 years ago
<SPACER> tag does not render
<SPACER> tag does not render properly if at all. <SPACER> is supposed to take up an area of space which the browser is supposed to take into consideration for rendering. Works in NS 4.61. Doesn't work in M12 Build ID 20000012116. See attached test case for details.
Moving to my list.
Assignee: rickg → harishd
Content-model looks right. .... table@0243812C border= cellspacing=0 cellpadding=0 refcount=10< tbody@0243849C refcount=3< tr@0243850C bgcolor=#ff99ff height=100px refcount=3< td@02438840 colspan=5 refcount=4< spacer@024389BC type=block height=100px width=100px refcount=3<> > > > > Text@02439650 refcount=3<\n\n> > > Redirecting bug to karnaze.
Assignee: harishd → karnaze
Reassigning to Kipp's bug list.
Assignee: karnaze → kipp
should at least diagnose this before beta1
Target Milestone: M15
I investigated this bug, here are my (somewhat unorganized) notes: nsHTMLSpacerElement::StringToAttribute() (in layout/html/content/src/nsHTMLSpacerElement.cpp) calls nsGenericHTMLElement::ParseValueOrPercent() for width or height attributes. Then, in nsGenericHTMLElement::ParseValueOrPercent() (in layout/html/content/src/nsGenericHTMLElement.cpp): when tmp.ToInteger(&ec) is called, the resulting ec != NS_OK. Since ec != NS_OK, aResult.SetPixelValue(val) is not called, like it should be. Then, in SpacerFrame::Reflow() (in layout/html/base/src/nsSpacerFrame.cpp): for width and height attributes, val.GetUnit() is returning 10 (eHTMLUnit_String). width and height for nsHTMLReflowMetrics are 0 unless val.GetUnit() returns 600 (eHTMLUnit_Pixel). In builds before bug 24770 appeared, for width and height attributes, val.GetUnit() was returning 600 (eHTMLUnit_Pixel). Bug 24770 does not appear in M12 release and previous. Bug 24770 does not appear in 2000-01-17-08-M13 Bug 24770 appears in 2000-01-19-08-M13 cvs log for mozilla/xpcom/ds/nsString2.cpp Rev Author Date Log 1.67 rickg%netscape.com Feb 13 09:46 major perf mods for bug 27524, and removed deprecated methods; r=harishd 1.66 rickg%netscape.com Feb 11 07:19 added return type on new method 1.65 rickg%netscape.com Feb 11 04:11 fixed25049; r=harishd 1.64 rickg%netscape.com Jan 18 13:06 bug24015; r=rods a=chofmann 1.63 rickg%netscape.com Dec 2 1999 fixed PDT+19121; r=kmcclusk It looks like bug 24770 first appeared when rev 1.64 of nsString2.cpp landed. I built mozilla from m13 source, then I rebuilt libxpcom with nsString2.cpp rev 1.63 instead of rev 1.64, then bug 24770 does not appear. It doesn't look like nsString2.cpp rev 1.64 is incorrect though, I think the issue is with including "px" at the end of the spacer width and height. Bug 24770 does not appear if "100" is used for spacer width and height, instead of "100px". Maybe the "px" should be stripped off of "100px" before calling nsAutoString::ToInteger in nsGenericHTMLElement::ParseValueOrPercent() (in layout/html/content/src/nsGenericHTMLElement.cpp) "px" is a valid unit of measure in CSS, is "px" valid for HTML width and height attrs? "100px" works for spacer width/height in Nav 4. Is this a Nav 4 quirk?
mine! mine mine mine! all mine! whoo-hoo!
Assignee: kipp → buster
moving all buster m15 bugs to m16.
Target Milestone: M15 → M16
After a little research, technically speaking, no px is not part of the HTML 4.01 DTD specification for length attributes. http://www.w3.org/TR/html4/sgml/dtd.html#Length However, it is implemented in both NS 4.6 and MSIE 5.0 for <td> and <spacer> tags. It is also implemented for style attributes for <spacer> tags in MSIE but not for NS 4.6. The matrix test case makes it easier to visually compare behavior across different browser implementations.
great analysis and great test case. all this should make fixing this very straightforward.
Status: NEW → ASSIGNED
The spacer code was old and crusty. I rewrote it to behave properly in the modern world. It's still not 100% accurate, but it's sufficiently far along to close this bug (when I check it in.) The matrix posted by file:///s:/testcases/spacer1.html lays out great...better than in Nav 4 or IE 5 in fact. Any specific bugs should be reported separately. ETA for checkin: this weekend.
Whiteboard: fix in hand
fix checked in
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Whiteboard: fix in hand
Looks fine in the May 30th builds. Marking verified fixed.
Status: RESOLVED → VERIFIED
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.