Closed Bug 24770 Opened 20 years ago Closed 20 years ago

<SPACER> tag does not render

Categories

(Core :: Layout, defect, P3)

x86
Windows NT
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: dciemo, Assigned: buster)

Details

Attachments

(3 files)

<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.
Attached file Test case.
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.