Plugin Finder Service is not invoked for OBJECT element

RESOLVED WONTFIX

Status

()

Core
Plug-ins
P3
normal
RESOLVED WONTFIX
15 years ago
3 years ago

People

(Reporter: Arun Ranganathan, Assigned: Peter Lubczynski)

Tracking

Trunk
Future
x86
Windows 2000
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [PL2:NA])

Attachments

(2 attachments)

(Reporter)

Description

15 years ago
Currently, for code like this:

<object id="myFlash" data="javascript_to_flash.swf"
type="application/x-shockwave-flash" width="366" height="142">
    	<param name="movie" value="javascript_to_flash.swf">
    	<param name="quality" value=high>
    	<param name="swliveconnect" value="true">    	
</object>

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

Comment 1

15 years ago
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.
(Reporter)

Comment 2

15 years ago
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

Comment 3

15 years ago
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.

Updated

15 years ago
Priority: -- → P4
Whiteboard: [beppe: Check with HTML WG]
Target Milestone: --- → mozilla1.4beta
(Reporter)

Comment 4

15 years ago
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.
(Reporter)

Comment 5

15 years ago
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.

Comment 6

15 years ago
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
alternative text.

Comment 7

15 years ago
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.
Keywords: nsbeta1
Whiteboard: [beppe: Check with HTML WG] → [PL2:NA]

Comment 8

15 years ago
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.

Comment 9

15 years ago
reassigning to Anthony
Assignee: beppe → anthonyd
Keywords: nsbeta1 → nsbeta1+
Target Milestone: mozilla1.4beta → mozilla1.3beta

Comment 10

15 years ago
peterl
Assignee: anthonyd → peterl
nsbeta1-. Peter is overloaded with higher priority issues.
Keywords: nsbeta1+ → nsbeta1-
Priority: P4 → P3
Target Milestone: mozilla1.3beta → Future
BTW: This is also true for the Firefox PFS replacement content.
QA Contact: shrir → plugins
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.)
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.