116027 - Handle <embed> and <object> with helpers if no plugin is available

Status: RESOLVED INVALID

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

Description

[Boris Zbarsky [:bzbarsky]]

BUILD: any

STEPS TO REPRODUCE:
1) Configure a helper application for audio/wav
2) Make sure you have no plugins that handle audio/wav
3) Load a page that <embed>s a wav file (eg http://www.brainless.org)

HOPED-FOR RESULTS:
Browser uses the helper to display the content (since there is no prompt for a 
plugin in this case, presumably because no width/height are set on the <embed>)

ACTUAL RESULTS:
Nothing.  No sound, no prompt to get the plugin, no indication that the <embed> 
is present.

It seems to me that we should make the effort to use helper apps to display the 
embedded content in this case.

Similarly, once the XBL plugin placeholder is in place, I feel that it should 
offer both an "install plugin" option and a "view with helper" option.

See related bug 30733.  This is distinct from that, since in my opinion there is 
no reason not to spawn the helpers externally (outside the Mozilla window).

Comment 1

[Hixie (not reading bugmail)]

Similarly, if we support a type natively (e.g. SVG) and we don't have a plugin,
then we should render the SVG natively. See, e.g.:
   http://svgmagic.com/demos/chamelion/chamelion.html

Comment 2

[Boris Zbarsky [:bzbarsky]]

don't we already do <object> and <embed> correctly for image types (eg GIF) we 
support natively?  The same should work for SVG...

Comment 3

[sc]

i've heard that moz will render whatever natively-supported <object> types; as
for <embed>, it's not yet supported in the same way, even when the <embed>-ed
thing has a natively supported MIME type.


For the specific case of SVG, this is a thorn in the side of folks who want to
make "SVG-enabled" pages that will appear the same, to users of both Mozilla and
of the Adobe SVG plugin; apparently, the Adobe SVG plugin uses the <embed>
element, which moz does not yet support in the way that the original reporter of
this feature-request (and myself, and probably others) would like. 

Some of the rationale for adding the feature:

Mozilla supports inline SVG, and SVG via <object>, which is wonderful, but why
should i or anyone else have to install the adobe plugin, just to get moz to
render SVG which has been included via <embed> elements? It's not right. Mozilla
has /native/ support for SVG, so it should use itself for rendering the 'src' of
an <embed> element, when that 'src' has a natively-supported MIME type, e.g.:
image/svg+xml, or audio/wav.


Proposal:
 when mozilla encounters an <embed> element, with a 'type' that is
natively-supported, then cause mozilla to attempt to "cast" that <embed> element
as an <object>, and handle it equivalently.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Um... No. This bug is specifically on using _helpers_ if the browser has no 
internal means (built-in or plugins) to render content.  Please file a separate 
bug (if one does not already exist, which I doubt) on our broken <embed> 
handling.

Comment 5

[Boris Zbarsky [:bzbarsky]]

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

Comment 6

[Sergey Lunegov]

Attachment: patch

This patch fixes the problem in case of embedded plugins

Comment 7

[Sergey Lunegov]

I added the attachment #67888 [details] [diff] [review]: this patch fixes problem in case of 
embedded plugins. I think that similar code (as in nsObjectFrame.cpp)
should be added to nsPluginViewer.cpp (in case of full page plugins).

Comment 8

[rubydoo123]

The plug-ins triage team (av, beppe, peterl, serge and shrir) have reviewed this
issue and have made the following determination:

Setting to future, we will readdress this request at a later date

Comment 9

[Boris Zbarsky [:bzbarsky]]

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

Comment 10

[Cesar A. Groh]

That patch (attachment #67888 [details] [diff] [review]) seems to be for Linux.
Does anyone have something for Windowz users?
Groh.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 67888 [details] [diff] [review]
patch

Wow.  Way to ignore a contributed patch for a year or so...  No wonder getting
new developers is so hard.  

Peter, what do you think of this general approach?  I don't really know much
about the plugin end of this (see below for the helper apps end).

Note that this patch is NOT Linux-only -- it will work on any platform on which
nsIExternalHelperAppService::CanHandleContent is implemented in a reasonable
way.  At the moment, that function returns PR_FALSE on all platforms for all
types, but that could be changed without too much trouble...

Comment 12

[Peter Lubczynski]

Comment on attachment 67888 [details] [diff] [review]
patch

The approach looks fine but keep in mind that it will be subject to bug 157554.
A preference or some placeholder UI would also be nice and this needs to be
updated to the trunk.

One alternate idea is to use a child frame frame as alternate content to load a
xul document to do things like this or replace the default plugin.

Comment 13

[Peter Lubczynski]

-->default owner

Comment 14

[Boris Zbarsky [:bzbarsky]]

Sergey, do you have time to work with Peter on this?

Comment 15

[R.K.Aa.]

related: bug 240408

Comment 16

[Benjamin Smedberg]

csonne, I think we should probably do this as part of removing PFS.

Comment 18

[Anne (:annevk)]

We're no longer in the plugin business (apart from PDFs).