157554 - Failure to instantiate plugin in nsPluginStreamListenerPeer::OnStartRequest does not cause us to layout alternate renderings

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect, P2)

Description

[Peter Lubczynski]

Sometimes plugin code needs to open the stream of an OBJECT (or EMBED) tag in
order to find out the mime-type to use. We do not handle failure here gracefully.

For example:

<object data="missing.file" width=100 height=100>
  Alternate Rendering
</object>

This fails becuase layout never gets a call to CantRenderReplaceElement in
OnStartRequest.

Another similar case that fails is when we are only able to determine the
mime-type from the HTTP header and it's not a handled by a plugin, we never give
layout a chance to see if it can handle it. 

For example:
<object data="http://www.mozilla.org/ width=100 height=100></object>

This fails because a new child nsFrameFrame or nsImageFrame are not created in
OnStartRequest.

I'm investigating on ways to fix this. Calling back into layout for replacement
probably isn't a problem. However, we need to ensure we do not make two requests
when trafering control to the IFRAME or IMG tag code.

Comment 1

[Peter Lubczynski]

Since this is sort of serious and I have sort of an idea of how to fix it now,
lets try to get this done in the near-term....of course if plugins move to
content in bug 90268, this bug would be a good learning experience :)

Comment 2

[Peter Lubczynski]

*** Bug 156199 has been marked as a duplicate of this bug. ***

Comment 3

[Peter Lubczynski]

*** Bug 157150 has been marked as a duplicate of this bug. ***

Comment 4

[rubydoo123]

1.3 beta

Comment 5

[Peter Lubczynski]

*** Bug 175465 has been marked as a duplicate of this bug. ***

Comment 6

[John Schoenick [:johns]]

bug 745030 should either fix this or make it a much simpler fix

Comment 7

[John Schoenick [:johns]]

This was fully fixed by 745030, although most cases of it had been fixed previously.