109082 - Outer most nested OBJECT element is rendered even if unknown

Status: RESOLVED INVALID

(Core Graveyard :: Plug-ins, defect, P3)

Description

[rubydoo123]

I know the Summary is lame, but I wasn't sure how to reduce the issue down

If there are multiple nested object elements, and even if the object is unknown, 
the object is processed. In this test case, the outer most object should be 
ignored.

Not sure if this one should be a separate bug, if it should just let me know and 
I will open a new one: but why is the outer most object rendered several pixels 
down and one or two pixels over to the right?

Comment 1

[rubydoo123]

Attachment: the image that should be displayed

The attached image should be the only thing displayed in this test

Comment 2

[rubydoo123]

Attachment: image for the nested objects

this image should not be displayed at all in the test

Comment 3

[rubydoo123]

Attachment: test case

test case showing the issue

Comment 4

[rubydoo123]

Attachment: updated test case

Comment 5

[rubydoo123]

don't use the updated one, I changed the image ref to the attachment name, but 
it didn't work like I expected, the first attachment (57054) should be renamed 
to correct.gif, the second image (57057) should be named to incorrect.gif

Comment 6

[scottputterman]

Moving Netscape owned 0.9.9 and 1.0 bugs that don't have an nsbeta1, nsbeta1+,
topembed, topembed+, Mozilla0.9.9+ or Mozilla1.0+ keyword.  Please send any
questions or feedback about this to [e-mail].  You can search for
"Moving bugs not scheduled for a project" to quickly delete this bugmail.

Comment 7

[rubydoo123]

Ok, let me try and explain this in more detail.

The problem, as I see it, is that attributes of the outer most object element
are being processed, even though we do not recognize the plug-in. The outer most
object element has a CSS property assigned to it via the style element in the
head. The CSS is written to display the outer object element with a red background:
object {border: thin red solid; background: red}

Since the object element is coded with an unknown plug-in:
  <object type="image/foo" data="foo.foo">

It should not be processed, we should be falling through to the next object
element, one which we can process.

What happens is that the red box is displayed and the word CORRECT! is displayed
on top of it, but shifted up and to the left a bit. The word fix is what is
being pointed to in the nested object:
<object type="image/gif" data="correct.gif">

Comment 8

[Peter Lubczynski]

This problem is likely caused by bug 157554 although it could be a dup of one of
the dependencies. Layout doesn't do the right thing [in rendering nested OBJECT
tags] when we need to make decisions based on the DATA returned from Necko.

Comment 9

[Peter Lubczynski]

I think this bug may be fixed with the patch in bug 136927.

So the basic problem here is
1. we try TYPE, don't have a plugin for image/foo
2. second we try DATA, we could not open the URL because foo.foo does is not valid

Bug 136927 deals with valid URLS and what to do if there are no plugins for the
mime type handded back from the stream. Since foo.foo is not valid at all, the
patch in bug 136927 is able to tell layout to try to render the contents (i.e.
the embed tag).

Comment 10

[rubydoo123]

moving to 1.4 beta : plug-in branch work

Comment 11

[Christian :Biesinger (don't email me, ping me on IRC)]

I'm not sure this is a bug...

Comment 12

[Boris Zbarsky [:bzbarsky]]

Yeah, this looks invalid to me -- we should render the background/border/etc of
the <object> even if we're rendering its fallback content.  Imo, of course.

Comment 13

[David Balch]

Hi. I think that not rendering the borders, etc. of <objects> is the correct behaviour:
 * IMHO, that's what authors would expect to happen.

 * http://www.w3.org/TR/html401/struct/objects.html#h-13.3.1 seems to imply that the border shouldn't be rendered - see object rendering precedence rule 2: "If the user agent is not able to render the object"... i.e. if we don't support the data/type in the outer <object>, we don't render that object at all, instead just go to the fallback content.

 * Interop: IE6 and Opera 8.5 appear to only render borders for the fallback content.

Comment 14

[Boris Zbarsky [:bzbarsky]]

OK.  Let's ask this differently.  If I have:

  <object style="position: absolute; width: 100px; height: 100px;">
    fallback
  </object>

And I have to render the fallback, should it be positioned?  Should it be in a 100px by 100px box?  How is this different from the border case, if at all?

Basically, in HTML <object> fallback is so ridiculously badly underspecified that it's not even funny.  So the question is what CSS boxes fallback should actually produce; once that's decided the rendering becomes obvious (and determined by the CSS specification).

Note that object fallback in IE is so broken that I'm not even going to bother looking at what IE does.  ;)

One other possibility, I suppose, would be to make the object visibility:hidden and make its kids visibility:visible.  That way the object will lay out as it should, but not actually paint.  But notice that in that case the borders will take up space in these testcases.  Just not paint.

Comment 15

[David Balch]

Re comment #14:

All good points.

>And I have to render the fallback, should it be positioned?  Should it be in a 100px by 100px box?

I think it shouldn't. If that's what the author wants, they assign those styles* to the fallback as well, e.g.

<object style="position: absolute; width: 100px; height: 100px;">
    <div style="position: absolute; width: 100px; height: 100px;">fallback</div>
</object>

It's posible that an author will want the fallback to use totally different settings, so inheriting from a non-rendered <object> could get in the way. At the least it would be confusing.
Either the <object> should render, or it should not render - not something in between.

*Or a class, of course.

Comment 16

[Boris Zbarsky [:bzbarsky]]

OK, how do you reconcile that with the CSS box model?  Specifically, once we fall back, is the object still a replaced element?

Comment 17

[David Balch]

Ideally any replaced element generated for a non-rendered <object> (nro) would be discarded, and the layout (and any fallback content) should work as if the nro never existed.

I guess this would be interesting if we decided to edit the nro using DOM and it became renderable, as it would then need to be inserted back into the layout.

Apologies if I'm missing the point somehow - this is around the limits of what I've dealt with before, and I have no idea whether this would be difficult for Gecko to do.

Comment 18

[Boris Zbarsky [:bzbarsky]]

The point is, in CSS you get boxes corresponding to DOM nodes (unless the DOM node is display:none).  What sort of box should the <object> DOM node get?

Comment 19

[Christian :Biesinger (don't email me, ping me on IRC)]

fwiw, see the CSS specification for what a "replaced element" is

Comment 20

[David Balch]

Ah, right. We can't somehow pretend that the object node isn't in the DOM at layout, as I was vaguely thinking.

Does the type of box derive from normal flow rules? - inline in an inline formatting context; block in a block formatting context; width and height no greater than the fallback content.

It should be as if the nro isn't there, so perhaps visibility:none; border:0; margin:0; would do the job. It seems rather hackish, but also setting overflow:visible; and width and height to zero or 1px would prevent it from taking up more space than a fallback of small width and height.

Re #19: Yeah, I had checked http://www.w3.org/TR/REC-CSS2/conform.html#replaced-element, and it's what I suspected :-)

Comment 21

[Boris Zbarsky [:bzbarsky]]

> Does the type of box derive from normal flow rules? 

Right now it derives from the value of "display" on the <object> node.  And if display is block, then the height and width properties affect the sizing, etc.

> It seems rather hackish, but also setting overflow:visible; and width and
> height to zero or 1px

This wouldn't work, since then the fallback content wouldn't affect sizing of the parent of the object.

Oh, and if the object is inline width and height don't apply anyway....

So if the object is a block, what should happen for sizing?

Comment 22

[Hixie (not reading bugmail)]

CSS applies to the <object> element even if it isn't a replaced element. This bug is invalid. HTML5 will be a whole heck of a lot clearer on this.