Closed
Bug 15019
Opened 25 years ago
Closed 24 years ago
OBJECT elements pointing to non-existant GIFs do not CantRenderReplacedContent...
Categories
(Core :: Layout, defect, P3)
Tracking
()
VERIFIED
WORKSFORME
M17
People
(Reporter: ian, Assigned: serhunt)
References
()
Details
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.
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
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
Comment 3•25 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•25 years ago
|
Status: RESOLVED → REOPENED
Reporter | ||
Updated•25 years ago
|
Resolution: DUPLICATE → ---
Reporter | ||
Comment 4•25 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.
Reporter | ||
Comment 5•25 years ago
|
||
Comment 6•25 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.
WFM on NT.
Status: REOPENED → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•