Currently, for code like this:
type="application/x-shockwave-flash" width="366" height="142">
<param name="quality" value=high>
<param name="swliveconnect" value="true">
the PFS (Plugin Finder Service) is not invoked. In bug 134445 we saw to it that
the 'codebase' attribute plays the same role as the 'pluginurl' attribute in the
old 'embed' element.
But in the old 'embed' element, if you never specified a pluginurl, the PFS
would be invoked. That's not the case for the object element.
Expected Behaviour: NOT specifying an obtention path should invoke the PFS as in
the case of the embed element.
Actual Behavior: This is not the case.
Created attachment 106448 [details]
HTML4.01 validating page with OBJECT element and no obtention path...
The HTML page makes use of an SWF file that I am also attaching so that you can
put the two together and use them in a single directory.
Created attachment 106450 [details]
SWF file used in the sample HTML (previous HTML)
This is an SWF file of MIME type application/x-shockwave-flash
we will need to construct a mechanism if the media type is missing and trigger
off the data type, at least for now. As the XHTML specs come into play, this may
be against the spec requirements.
I'm proposing that if the object is missing, at LEAST display the missing jigsaw
puzzle piece. Then the user can click on it and search the PFS for it.
Currently, if the object is missing, we display nothing.
It would be truly unfortunate if doing this minimal feature violated a spec.,
because then the object tag's functionality would be a bit under par compared to
embed tag, which at least displays the missing jigsaw piece.
Further: if there are nested object tags, keep going till you find one you can
display (as the HTML 401 spec. suggests). But if you can display none, display
the missing jigsaw piece for the outermost element. In the case of a solitary
object element, if it is missing, display the missing puzzle piece just as we do
for solitary embed elements.
We discussed this particular functionality request at the W3C HTML Working Group
meeting this morning. Per the discussion, this feature would be in direct
opposition of the standard. It is the responsibility of the author to include
alternate text, the author may have indeed meant to not process/render anything
if the object cound not be found. The user agent SHOULD NOT provide additional
information if the object could nto be processed and the author did not supply
To promote a positive user experience and to be consistent within the
application, we will follow the img model. In quirks mode we will display the
puzzle piece and in standards mode (usage of appropriate doctype) we will
suppress the puzzle piece.
The current state is to display nothing.
let me finish that comment: if teh inner most object does not contain any nested
information, i.e %block or %inline, then the puzzle piece should be rendered.
reassigning to Anthony
nsbeta1-. Peter is overloaded with higher priority issues.
BTW: This is also true for the Firefox PFS replacement content.
Bug 836415 has now removed the Plugin Finder Service (PFS) from Firefox. As a result, I'm closing all the remaining PFS bugs.
If you're getting this bugmail for an ancient PFS bug, the basic summary of the world today is:
* NPAPI plugins are a dying technology
* PFS was already restricted to assisting with only the 4 most common plugins
* Sites commonly provide their own UI for install a required plugin
* Mozilla is generally focusing on improving the web platform so that proprietary plugins are not required.
(Note that "plugins" are a completely separate from "browser extensions", such at those found on addons.mozilla.org. The latter are not going anywhere, and are not impacted by the removal of PFS.)