Closed Bug 22037 Opened 20 years ago Closed 20 years ago

[BLOCK] <object> in inline containing block does not display. {ib}


(Core :: Layout, defect, P3)






(Reporter: Sebastian, Assigned: waterson)




(Whiteboard: fix in hand)


(4 files)

Seeing in build 12/16 on Linux

Page contains following lines:
  <A href="about.html">

When loading a box [object] appears and disappears, but then nothing but a
transparent space shows up where the object should be. It does work as a link as
HTML validator shows the page as strict 4.0 compatible, is <object> not yet
Oops, sorry for the typo in former post:
 It does *not* work as a link!
Assignee: rickg → kipp
This is well formed and correct as far as the parsing engine is concerned. It
appears to be a layout bug.
Blocks: html4.01
Summary: <OBJECT> embedded in <a href="..."> does not work as link → <object> in inline containing block does not display. {ib}
The problem occurs if there is a CSS block inside the object and the object
is stored in an inline element.

   <span><object><span style="block"> should show </span></object></span>
...will not display.

A simple test case is here:
mass moving all Kipp's pre-beta bugs to M15.  Nisheeth and I will
prioritize these and selectively move high-priority bugs into M13 and M14.
See also these test cases:
They demonstrate bug 797, bug 15019 and bug 22047 (this one) respectively, see
also bug 678.

Petersen: I'm the QA contact for HTML 'alt text' bugs, if you think that the
object elements' alternate content classifies as 'alt text' then feel free to
put me in as QA contact for this bug.
Summary: <object> in inline containing block does not display. {ib} → [BLOCK] <object> in inline containing block does not display. {ib}
This is kind of weird.  Ian's test case
works perfectly on Linux build 2000020708 - but if I change the
<span style="display:block"> back to <h2> (as in original bug report), the bug 
is back.

See for yourself - the modified test is at

This also occurs on WinNT4 SP6, build 2000020817 - so I'm changing OS to All.
OS: Linux → All
Updating the URL field while I'm there.
My test case doesn't work perfectly on Win32 build of 2000021808:

(Antti: your test case is coming up "403 Forbidden".)
mine! mine mine mine!  all mine!  whoo-hoo!
Assignee: kipp → buster
Could it be, that this is a manifestation of bug 28553? Citing a comment from there:
>It looks like the primary frame is not found because of a side effect of a
>change Kipp made in how he handles blocks within inlines.
>For example, for something like this: <SPAN>Some text <DIV>Nested div</DIV>
>more text</SPAN>
moving all buster m15 bugs to m16.
Target Milestone: M15 → M16
nisheeth is now working on {ib} bugs
Assignee: buster → nisheeth
Accepting bug...
Blocks: 40246
I think this may just be a control-flow issue in 
nsCSSFrameConstructor::ConstructFrameByTag(). It looks like in the case of the 
<object> tag, we never recurse to build any of its children. Dumping the frame 
model confirms this, showing no frames ever got constructed beneath the inline 
frame for the object.
Attached file reduced test case
The children of an OBJECT element should only be displayed if the object cannot
be displayed.  I believe that works in most cases (but not sure).  So the
problem could be in the logic that decides when to use the contents, or
Assignee: nisheeth → waterson
Target Milestone: M16 → M17
nisheeth: yet another block-in-inline bug. can you r=?
Noting fix in hand, awaiting review. Nominating for nsbeta2 on the basis that 
it will cause pages to render incorrectly if a user doesn't have a plugin 
installed. It is common practice to use the text inside an <object> or <embed> 
tag to give a user plugin download instructions (or provide other alternate 
information) if the plugin cannot be downloaded.
Keywords: nsbeta2
Whiteboard: fix in hand
Here's what the patch does.

1. In the initial state, you've got a block frame B that contains a bunch of
inline frames eventually winding down to the <object> frame o 


2. The object frame o gets split into the left inlines (o), the block frames
(O), and the right inlines (o'). 

               o O o'

3. We call SplitToContainingBlock(), which will split 2 as follows. 

              /          \
         b-->2   2*  2'   b'
             |   |   |
             o   O   o'

Note that 2 gets split into 2* and 2', which correspond to the anonymous block
and inline frames, respectively. Furthermore, note that 2 still refers to b' as
its next sibling, and that 2' does not. If 2 has a continuation frame, then
we'll break that link now, as well.

4. We recurse again to split 1. At this point, we'll break the link between 2
and b', and make b' be the next sibling of 2'. 

              /             \
         a-->1      1*  1'   a'
             |      |   |
             b-->2  2*  2'-->b'
                 |  |   |
                 o  O   o'

As with 2, 1 retains a' as its next sibling. 

5. When we hit B, the recursion terminates. We now insert 1* and 1' immediately
after 1, resulting in the following frame model. This is done using the "normal"
frame insertion mechanism, nsIFrame::InsertFrames(), which properly recomputes
the line boxes. 

               |       |    |
               b-->2   2*   2'-->b'
                   |   |    |
                   o   O    o'

Since B is a block, it is allowed to contain both block and inline frames, so we
can let 1* and 1' be "real siblings" of 1.

fix checked in, r=nisheeth
Closed: 20 years ago
Resolution: --- → FIXED
Testcase works, original case works, marking verified, but:
When you look at the original case (see the line below) at you will get links now with a mouse pointer being a
caret(?) and not a hand. Is this correct?

<A href="about.html"> <OBJECT> <H2>About</H2> </OBJECT> </A>
Well, I'd say that sounds wrong to me. Would you mind opening another {ib} bug
on that case?
[parenthetic note: the last comment about 'caret' over link if %block; content 
was ultimately filed as bug 54801, if nowhere else, but it appears to be fixed]
SPAM. HTML Element component is deprecated, changing to Layout component. See
bug 88132 for details.
Come on Bugzilla, you can do it...
Component: HTML Element → Layout
You need to log in before you can comment on or make changes to this bug.