Outer most nested OBJECT element is rendered even if unknown

RESOLVED INVALID

Status

()

Core
Plug-ins
P3
normal
RESOLVED INVALID
17 years ago
12 years ago

People

(Reporter: rubydoo123, Assigned: Peter Lubczynski)

Tracking

({html4, testcase})

Trunk
mozilla1.4beta
x86
All
html4, testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [PL:BRANCH][HTML4-13.3.1], URL)

Attachments

(3 attachments, 1 obsolete attachment)

(Reporter)

Description

17 years ago
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?
(Reporter)

Comment 1

17 years ago
Created attachment 57054 [details]
the image that should be displayed

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

Comment 2

17 years ago
Created attachment 57057 [details]
image for the nested objects

this image should not be displayed at all in the test
(Reporter)

Comment 3

17 years ago
Created attachment 57058 [details]
test case 

test case showing the issue
(Reporter)

Comment 4

17 years ago
Created attachment 57059 [details]
updated test case
Attachment #57058 - Attachment is obsolete: true
(Reporter)

Updated

17 years ago
Attachment #57058 - Attachment is obsolete: false
(Reporter)

Updated

17 years ago
Attachment #57059 - Attachment is obsolete: true
(Reporter)

Comment 5

17 years ago
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

Updated

16 years ago
Keywords: mozilla1.0
Priority: -- → P3
Target Milestone: --- → mozilla1.0

Comment 6

16 years ago
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 adt@netscape.com.  You can search for
"Moving bugs not scheduled for a project" to quickly delete this bugmail.
Target Milestone: mozilla1.0 → mozilla1.2
(Reporter)

Comment 7

16 years ago
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">
(Reporter)

Updated

16 years ago
Whiteboard: [PL2:NA]

Comment 8

16 years ago
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.
Depends on: 157554
Keywords: testcase
OS: Windows 98 → All
Summary: Outer most object element is rendered even if unknown → Outer most OBJECT element is rendered even if unknown
(Reporter)

Updated

16 years ago
Blocks: 133818
Keywords: html4
Whiteboard: [PL2:NA] → [PL2:NA][HTML4-13.3.1]

Comment 9

16 years ago
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).
Depends on: 136927
(Reporter)

Comment 10

16 years ago
moving to 1.4 beta : plug-in branch work
Whiteboard: [PL2:NA][HTML4-13.3.1] → [PL:BRANCH][HTML4-13.3.1]
Target Milestone: mozilla1.2alpha → mozilla1.4beta
I'm not sure this is a bug...
Depends on: 1156
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

13 years ago
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.
Summary: Outer most OBJECT element is rendered even if unknown → Outer most nested OBJECT element is rendered even if unknown
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

13 years ago
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.
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

13 years ago
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.
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?
fwiw, see the CSS specification for what a "replaced element" is

Comment 20

13 years ago
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 :-)
> 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?
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.
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.