Closed Bug 59837 Opened 20 years ago Closed 13 years ago

{ib} body { display: inline } causes contents to dissapear


(Core :: Layout: Block and Inline, defect, P1, major)






(Reporter: ppmozilla, Unassigned)




(Keywords: css1, testcase, Whiteboard: [CSS1-5.6.1])


(6 files, 1 obsolete file)

From Bugzilla Helper:
User-Agent: Mozilla/4.75 [en] (Win98; U)
BuildID:    2000110904 (or 20001102?? or M18 or M17)

Will not render the page (except bgcolor), but it pass all tests at W3C org ( ).  And it works for Communicator 4.75 and IE 5.  
Documented as png's at:  and  and  and  and
The problem seems to be that the display attribute of body is set to inline.

Commenting out that one line in the stylesheet fixes the problem.

What should our behavior be when we run into BODY { display: inline }?
Assignee: asa → pierre
Component: Browser-General → Style System
QA Contact: doronr → chrisd
Sorry, some of the png addresses are wrong, where ...Validator.. is there should 
be:  and  and

I have removed BODY { display: inline } from the stylesheet now (Thank you 
Boris!).  Thomas
Confirming, though I don't really get what display:inline would do in a BODY.
Ever confirmed: true
Could someone please attach a testcase?

Hixie: so what should that css do?

Clarifying summary.
Severity: major → normal
Keywords: qawanted
QA Contact: chrisd → ian
Summary: Will not render the page (except color). → Page content w/ css[BODY { display: inline }] does not render
Attached file Testcase (obsolete) —
In testcase #2, the body tag only contains inline children and is rendered

Also changing OS -> ALL, since I see this on Linux.
OS: Windows 98 → All
Hardware: PC → All
Setting <body> to display:inline is perfectly valid and should do the same as
setting a <div> to display:inline. Testcase and ref rendering coming up.
Assignee: pierre → buster
Summary: Page content w/ css[BODY { display: inline }] does not render → body { display: inline } causes contents to dissapear [INLINE]
Moving to m1.1
Target Milestone: --- → mozilla1.1
Build reassigning Buster's bugs to Marc.
Assignee: buster → attinasi
Whiteboard: [CSS1-5.6.1]
So.. Here is what's up.  We create the <body> frame quite early, apparently.  So
early that at that point the body nsIContent children.  This means that
ProcessInlineChildren will say that all the children (of which there are none)
are inline.  Thus the body does not get marked as "special", and appending
blocks to it doesn't do any of the magic fixup that should happen.

So one solution (the one that seems correct) is to have ContentInserted() and
ContentAppended() for a non-special inline frame check whether the frames that
are being inserted are blocks and if so mark the frame special and reframe the
whole thing.... Does that seem reasonable?
Will this fix bug 15462 too?
Most likely, yes.

By the way, Comment 14 meant to say "the body nsIContent has no children", not
"the body nsIContent children."
Ugh.  So even if the <body> frame is special things don't work...  We call
ReframeContainingBlock() on the body frame, which looks for the body's
containing block, and reframes it.  Do do this it gets the containing block's
nsIContent, gets that nsIContent's parent and "oops", there is no parent.  So it
can't pull its ContentReplaced(aPresContext, parentContainer, blockContent,
blockContent, index) trick because there is no parentContainer -- the
blockContent is the <html> element in this case.  Needless to say, bug 15462
will break one step earlier in this sequence of events....
Heh.  And if we have no parent block we do:

return RecreateEntireFrameTree(aPresContext);

and here is the gem:

nsCSSFrameConstructor::RecreateEntireFrameTree(nsIPresContext* aPresContext)
  // XXX write me some day
  return NS_OK;
This fixes ReframeContainingBlock() to use the right thing to blow away the
whole frame tree and fixes the code in ContentAppended() to check _all_ the
appended content.

If I now force the <body> frame to be marked special the testcase renders
correctly.  We don't always want it to be special, however.... so that's not a
very good approach.
might as well take this..
Assignee: attinasi → bzbarsky
Priority: P3 → P4
Target Milestone: mozilla1.1alpha → Future
If I add display:inline; to the CSS "*" tag, the page breaks up and the contents
of the CSS file are displayed!

Take the line out and the layout is perfect.

I'm on Mozilla 1.2, PC, Win98.

Here is the code. Check in IE6 to see what it should look like. (Sorry, can't
upload this as an attachment on this computer.)

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
<html xmlns="" xml:lang="en" lang="en">


* {font-family:verdana;

body {
 margin: 10px 10px 0px 10px;
 background-color: #fff;}

td {border: solid 1px #999;

td, th {background-color: #eee;}

a {font-family:verdana;

a:hover {color:#08f;}

img {vertical-align:top;}

.heading {font-weight:bold;
 border-bottom:1px solid #aab;}



<table align="left" cellpadding="8" border="0">
<tr><td><div style="width:140px; height:300px">
<div class="heading">SECTION 1</div>

<p><a href="">Link 1</a></p>

<p><a href="">Link 2</a></p>

<p><a href="">Link 3</a></p>


<td><div style="width:140px; height:300px">
<div class="heading">SECTION 2</div>

<p><a href="">Link 1</a></p>


<td><div style="width:140px; height:300px;">
<div class="heading">SECTION 3</div>

<p><a href="">Link 1</a></p>


<tr><td colspan="2">
<b>SECTION 4</b>
<br />Text that goes here

<td colspan="2">&nbsp;</td>


> Check in IE6 to see what it should look like.

IE's rendering is wrong here.  By default, in Mozilla, <head>, and <style> have
display:none, so they are not shown.  You set them to display:inline so we show
them.  Nothing wrong with that -- those elements are not in any way special as
far as a CSS browser (Mozilla) is concerned.

Further, that testcase has nothing at all to do with this bug.  This bug is
about having something with display:block inside a body that has display:inline.
 In your testcase, all the elements are display:inline, so this bug cannot arise.

(Oh, and if IE is not rendering that _exactly_ like Mozilla for the stuff inside
<body> then IE is just plain buggy; our rendering of that part is exactly
correct per CSS spec).
Originally the effect occured when I added display:inline; to the body tag. I 
see that now works okay in Moz 1.2. I wasn't aware that <head> and <style> were 
elements that could be displayed though. I thought they were only for the 
browser to know about internally (and the actual page content existing only in 
the <body> section.)

It now looks like IE *isn't* making the cells inline. The text is correctly 
displayed. I guess making everything inline was overkill on my part!
*** Bug 226606 has been marked as a duplicate of this bug. ***
Summary: body { display: inline } causes contents to dissapear [INLINE] → {ib}body { display: inline } causes contents to dissapear [INLINE]
No plans to work on this any time in the foreseeable future, so to default owner.
Assignee: bz-vacation → dbaron
Priority: P4 → --
Target Milestone: Future → ---
Summary: {ib}body { display: inline } causes contents to dissapear [INLINE] → {ib} body { display: inline } causes contents to dissapear
This is essentially the same as the first testcase, but it enables stylesheet
switching. The word "test" does not initially display, but it does display when
switching to Basic Theme and back to the default Display Inline theme.
Attachment #19117 - Attachment is obsolete: true
*** Bug 266453 has been marked as a duplicate of this bug. ***
*** Bug 280040 has been marked as a duplicate of this bug. ***
Assignee: dbaron → nobody
Severity: normal → major
Component: Style System (CSS) → Layout: Block and Inline
Priority: -- → P1
QA Contact: ian → layout.block-and-inline
Seems to work fine in FF 2.0 and on trunk
Closed: 13 years ago
Flags: in-testsuite?
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.