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

Status: VERIFIED FIXED

(Core :: Layout, defect, P3)

Description

[Sebastian Späth]

Seeing in build 12/16 on Linux

Page http://openprojects.nu contains following lines:
  <A href="about.html">
  <OBJECT>
  <H2>About</H2>
  </OBJECT>
  </A>

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
well.
HTML validator shows the page as strict 4.0 compatible, is <object> not yet
implemented?

Comment 1

[Sebastian Späth]

Oops, sorry for the typo in former post:
 It does *not* work as a link!

Comment 2

[rickg]

This is well formed and correct as far as the parsing engine is concerned. It
appears to be a layout bug.

Comment 3

[Hixie (not reading bugmail)]

The problem occurs if there is a CSS block inside the object and the object
is stored in an inline element.

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

A simple test case is here:
   http://www.bath.ac.uk/%7Epy8ieh/m/object-noattr.html

Comment 4

[buster]

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.

Comment 5

[Hixie (not reading bugmail)]

See also these test cases:
   http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/object-unknown.html
   http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/object-broken.html
   http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/object-noattr.html
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.

Comment 6

[Antti Näyhä]

This is kind of weird.  Ian's test case 
http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/object-noattr.html
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
http://www.netppl.fi/%7esairwas/tests/mozillabug-22037.html

This also occurs on WinNT4 SP6, build 2000020817 - so I'm changing OS to All.

Comment 7

[Antti Näyhä]

Updating the URL field while I'm there.

Comment 8

[Hixie (not reading bugmail)]

My test case doesn't work perfectly on Win32 build of 2000021808:
   http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/object-noattr.html

(Antti: your test case is coming up "403 Forbidden".)

Comment 9

[buster]

mine! mine mine mine!  all mine!  whoo-hoo!

Comment 10

[Sebastian Späth]

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>

Comment 11

[rickg]

moving all buster m15 bugs to m16.

Comment 12

[buster]

nisheeth is now working on {ib} bugs

Comment 13

[Nisheeth Ranjan]

Accepting bug...

Comment 14

[Chris Waterson]

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.

Comment 15

[Chris Waterson]

Attachment: reduced test case

Comment 16

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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
something...

Comment 17

[Chris Waterson]

taking

Comment 18

[Chris Waterson]

Attachment: proposed fix; add SplitToContainingBlock() method, invoke from CantRenderReplacedFrame().

Comment 19

[Chris Waterson]

nisheeth: yet another block-in-inline bug. can you r=?

Comment 20

[Chris Waterson]

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.

Comment 21

[Chris Waterson]

Attachment: more thorough test case

Comment 22

[Chris Waterson]

Attachment: more thorough patch

Comment 23

[Chris Waterson]

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 

       A-->B-->C
           |
           a-->1-->a'
               |
               b-->2-->b'
                   |
                   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. 

       A-->B-->C
           |
           a-->1------>1*-->1'-->a'      
               |       |    |
               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.

Comment 24

[Chris Waterson]

fix checked in, r=nisheeth

Comment 25

[Sebastian Späth]

Testcase works, original case works, marking verified, but:
When you look at the original case (see the line below) at
http://openprojects.nu 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>

Comment 26

[Chris Waterson]

Well, I'd say that sounds wrong to me. Would you mind opening another {ib} bug
on that case?

Comment 27

[John Morrison]

[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]

Comment 28

[Heikki Toivonen (remove -bugzilla when emailing directly)]

SPAM. HTML Element component is deprecated, changing to Layout component. See
bug 88132 for details.

Comment 29

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Come on Bugzilla, you can do it...