192204 - When ImageLib fails to display OBJECT image, fallback to contents doesn't occur

Status: RESOLVED FIXED

(Core :: Layout: Images, Video, and HTML Frames, defect)

Description

[Greg K.]

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.

Comment 1

[Greg K.]

Attachment: HTML testcase that nests a PNG OBJECT inside a JNG OBJECT

Comment 2

[Boris Zbarsky [:bzbarsky]]

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

Comment 3

[Hixie (not reading bugmail)]

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

Comment 4

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

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

Comment 5

[Boris Zbarsky [:bzbarsky]]

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?

Comment 6

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

duplicate of bug 96976 maybe?

Comment 7

[Boris Zbarsky [:bzbarsky]]

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

Comment 8

[Boris Zbarsky [:bzbarsky]]

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

Comment 9

[Peter Lubczynski]

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

Comment 10

[Boris Zbarsky [:bzbarsky]]

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?

Comment 11

[Peter Lubczynski]

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/">

Comment 12

[Boris Zbarsky [:bzbarsky]]

Fixed by bug 83774 checkin.

Comment 13

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

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.

Comment 14

[Greg K.]

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.

Comment 15

[Boris Zbarsky [:bzbarsky]]

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

Comment 16

[Greg K.]

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

Comment 17

[Boris Zbarsky [:bzbarsky]]

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

Comment 18

[Worcester12345]

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

Comment 19

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

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.