If ImageLib is unable to display an OBJECT image for some reason (such as that described in bug 192068), Mozilla doesn't try to display the OBJECT's contents, such as another nested OBJECT image or text. For example, FizzillaMach/2003020303 includes libmng 1.0.4, but that version has a bug that causes the JNG image in the attached testcase to fail to display. However, the referencing OBJECT contains an OBJECT that references an equivalent PNG image, but Mozilla doesn't attempt to display the PNG image.

This requires the <object> to know the image load failed....

I'm surprised that this isn't a dupe, it's pretty fundamental to the whole reason to have an <object>...

There's already code to handle this in nsCSSFrameConstructor::CantRenderReplacedElement. The question is only why that code isn't working.

Is that code even getting called? And if so, is it getting the right frame? <object> creates a child imageframe that has the same mContent as the object frame; would that matter?

duplicate of bug 96976 maybe?

Yep, that's the problem. We call CantRenderReplacedElement on the image frame, and it needs to be called on the object frame.... The problem is that the image frame construction succeeds, so the object has no good way to know that the image load failed. The simple fix for this is to use GetPrimaryFrameFor when deciding what frame to call CantRenderReplacedElement on in OnStopDecode.... I've rolled that into the patch for bug 83774, but I could attach a separate patch here if desired...

Oh, and this is thus somewhat separate from bug 96976 since it's specific to image <object>s. That said, the whole mess could use some improvement....

I think the problem may be that we never call CantRenderReplaceElement from the network stream code. See bug 157554.

With the current setup, I don't think the plugin stream ever gets even instantiated for images.... The <object> just relies on the frame to do the load (and will rely on the content node once bug 83774 lands). Or am I missing something?

The patch in bug 83774 looks similar to one I was working on to load all media that the OBJECT tag can handle from content and make common base classes for images and iframes. Currently, the code loads images (by creating a image frame) when the object frame is created and we detect we want an image from attributes. The problem that bug 157554 deals with is that if we are unable to detect this is an image from just looking at content's attributes, there is no way to trigger the image to load later from the plugin's stream code. This problem is analogous with IFRAMES in that we fail to render content like: <OBJECT data="http://www.mozilla.org/">

Fixed by bug 83774 checkin.

reopening... this seems to have issues. Load http://stud4.tuwien.ac.at/~e0225227/test.html if that displays the <object>'s alternate text ("Desert (this is alternate data)"), save it locally and display it from there. it doesn't display the text for me then.

Is that covered by bug 96976? To really test whether this bug is fixed, build with libmng 1.0.4 rather than 1.0.5 and view the testcase.

> Is that covered by bug 96976? No. That one only applies to plug-ins. Biesi and I are seeing at least two failure modes for the testase in this bug that still remain: 1) If image loading is turned off, we try to CantRenderReplacedElement from inside the ObjectFrame's Init() and that fails miserably -- we end up with no frame and no alt content. 2) Biesi is seeing a problem with local loads that may or may not be related to the underlying cause of problem #1 I suspect that fixing #1 properly will require moving <object> data loading into content....

Actually, bug 96976 doesn't only apply to plug-ins. See attachment 97463 [details].

Ugh. Well, that bug needs to be split into at least 3 separate bugs -- one for images, one for iframes, one for plugins.

(In reply to comment #17) > Ugh. Well, that bug needs to be split into at least 3 separate bugs -- one for > images, one for iframes, one for plugins. Please do it.

ok, so my testcase from 2.5 years ago is gone, and I can't remember what it contained. so I'm marking this fixed again: what bug 83774 didn't fix should've been fixed by bug 1156.