Boris Zbarsky [:bzbarsky] Reporter
	Description • 23 years ago

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

	Hixie (not reading bugmail)
	Comment 1 • 23 years ago

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

	Boris Zbarsky [:bzbarsky] Reporter
	Comment 2 • 23 years ago

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

	sc
	Comment 3 • 23 years ago

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.

	Boris Zbarsky [:bzbarsky] Reporter
	Comment 4 • 23 years ago

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.

	Boris Zbarsky [:bzbarsky] Reporter
	Comment 5 • 23 years ago

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

	Sergey Lunegov
	Comment 6 • 23 years ago

This patch fixes the problem in case of embedded plugins

	Sergey Lunegov
	Comment 7 • 23 years ago

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

	rubydoo123
	Comment 8 • 23 years ago

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

	Boris Zbarsky [:bzbarsky] Reporter
	Comment 9 • 22 years ago

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

	Cesar A. Groh
	Comment 10 • 22 years ago

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

	Boris Zbarsky [:bzbarsky] Reporter
	Comment 11 • 22 years ago

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

	Peter Lubczynski Assignee
	Comment 12 • 22 years ago

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.

	Peter Lubczynski Assignee
	Comment 13 • 22 years ago

-->default owner

	Boris Zbarsky [:bzbarsky] Reporter
	Comment 14 • 22 years ago

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

	R.K.Aa.
	Comment 15 • 21 years ago

related: bug 240408

	Benjamin Smedberg
	Comment 16 • 12 years ago

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