OBJECT elements pointing to non-existant GIFs do not CantRenderReplacedContent...

VERIFIED WORKSFORME

Status

()

P3
normal
VERIFIED WORKSFORME
19 years ago
18 years ago

People

(Reporter: ian, Assigned: serhunt)

Tracking

Trunk
x86
Windows 98
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

19 years ago
The following test page:
   http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/object-broken.html
...has the following markup:

   <object data="dead.gif" type="image/gif">
      <p>The image could not be fetched!</p>
   </object>

...but althought dead.gif does not exist, we never show the contents of the
OBJECT element. We just show nothing.

Note: This may be causing the crash in bug 15018.

Updated

19 years ago
Assignee: troy → av

Comment 1

19 years ago
Andre, what's happening is that the frame construction code gets notified that
the image can't be rendered and it removes the image frame. The object frame
code doesn't handle the RemoveFrame() call and so we hit an assert in nsFrame

The fix is not to have the object frame code handle RemoveFrame(), because we
don't want the image frame replaced, we want the object frame itself replaced
and its content displayed

I don't want the frame construction code checking for the image being a child of
the object, and so the best thing would be for the CantRenderReplacedElement()
call to notify the frame construction code that the _object_ can't be rendered

After all, the image frame is just an implementation detail of how the object
frame code works.

To get this right you probbaly need to have the object frame code notified that
the image can't be rendered. When you get that notification you notify the pres
shell that the object can't be rendered

Today what happens is that the object frame isn't in the loop

Comment 2

19 years ago
*** Bug 17499 has been marked as a duplicate of this bug. ***

Updated

19 years ago
Blocks: 18471
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED
Target Milestone: M14

Updated

19 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → DUPLICATE

Comment 3

19 years ago
Isn't this a dup of 797?  The basic problem seems to be identical: if there's
any reason (unknown MIME-type, missing file, missing 'data' attribute etc.)
which prevents the OBJECT from being rendered, the alternate content is not
displayed as it should.

Please reopen if you disagree.

*** This bug has been marked as a duplicate of 797 ***
(Reporter)

Updated

19 years ago
Status: RESOLVED → REOPENED
(Reporter)

Updated

19 years ago
Resolution: DUPLICATE → ---
(Reporter)

Comment 4

19 years ago
Nope, sorry, this is a different bug. In 797, the content is displayed. In this
bug, it is not. Different cause, different effect. Reopening.

Compare the results of 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 (this one) and bug 22047 respectively, see
also bug 678.

Comment 6

19 years ago
OK, you must be using a newer build.  I cannot see OBJECT content in 797

using the 1999121909 Linux build or the Dec 19 Windows installer build (cannot

test on newer builds right now), so I figured that these were duplicates.
(Assignee)

Updated

19 years ago
Target Milestone: M14 → M15
(Assignee)

Updated

19 years ago
Target Milestone: M15 → M17
(Assignee)

Comment 7

19 years ago
WFM on NT.
Status: REOPENED → RESOLVED
Last Resolved: 19 years ago19 years ago
Resolution: --- → WORKSFORME

Updated

19 years ago
No longer blocks: 18471

Comment 8

18 years ago
Verified
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.