134445 - OBJECT tag needs to be able to access default plugin if mimetype is missing

Status: VERIFIED FIXED

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

Description

[Arun Ranganathan]

This is similar to bug 46569 , but this bug is trying to get the OBJECT tag
working just as the EMBED tag does with the Plugin Finder Service (and thus the
default plugin).

The EMBED tag takes the form:
<embed type="application/xyz" src="myfile.xyz" height="45" width="55"
pluginurl="http://hereisxyz.com/myxyz.xpi"></embed> where myfile.xyz is of
mimetype "application/xyz", and if "application/xyz" handlers are missing from
Mozilla, the browser goes to the pluginurl OR pluginspage to obtain the binary
(DLL) that handles this type.  Currently, the best hook into the default plugin
and the plugin finder service is via the EMBED tag.  But this causes us to fall
short of the W3C spec., wherein OBJECT should do the nitty-gritty.  SO:

The proposal is:

2. <object type="application/xyz" data="myfile.xyz"
codebase="http://hereisxyz.com/myxyz.xpi"><param id="myparam" name="XYZ-Ident"
value="myXYXIdent"/></object>

Now here, just like embed tag's pluginurl attribute tells the browswer where to
get the plugin if a mime-type handler for "application/xyz" is missing, object
tag's codebase attribute tells the browser to get the plugin from the same
location.  We'll create a 1:1 mapping between the two tags, and hopefully allow
the default plugin to be invoked by OBJECT just as it is in EMBED.

Further notes: the W3C is vague on classid; thus, classid attribute can be used
in the same way that data attribute is getting used, but I advise against it. 
Let's leave classid (temporarily) to IE's ActiveX UUIDs. 

Bottom line: This bug seeks to wire the default plugin behavior (e.g.
npnul32.dll) to the Plugin Finder Service so that OBJECT can help locate plugins.

Comment 1

[Arun Ranganathan]

Nominating nsbeta1 per discussion with beppe.  Add "+" as you see fit.

Comment 2

[rubydoo123]

peterl

Comment 3

[Denis Antrushin]

Wait a minute! Codebase attribute of OBJECT tag  "specifies the base path used
to resolve relative URIs specified by the classid, data, and archive
attributes", not
points to url to get plugin from.

Comment 4

[rubydoo123]

moving this out to 1.1, planning needs to take place before this can happen

Comment 5

[Peter Lubczynski]

Problem:

Which OBJECT tag do we show the default plugin in a nesting situation like this:
<object type=SVG>
  <object type=FLASH>
     <object type=PNG>
        Alternate Text
     </object>
  </object>
</object>

Here are some possible ideas on how the HTML author can convey the fact that he
wants the default plugin to show up on a particular OBJECT tag:

1. Use an extra PARAM to act like pluginspage/pluginsurl, possibly like:
   <PARAM name="-moz-default-plugin" value="http://server.com/get_plugin.xpi">

2. Use an exsiting attribute on the OBJECT tag like CLASSID, CODEBASE, or
ARCHIVE to point to the pluginspage/pluginsurl like:
  <OBJECT type=SVG CLASSID="http://server.com/get_plugin.xpi">

3. Use a nested OBJECT tag explicitly asking for the default plugin:
  <OBJECT type=SVG>
     <OBJECT type="*">
       <PARAM name="pluginurl" value="http://server.com/get_plugin.xpi">
     </OBJECT>
  </OBJECT>

4. Use a CSS rule with special attribute matching (possibly with XBL):
   OBJECT[_mozShowDefaultPlugin] {
     -moz-binding: url(chrome://plugin/default.xml)
   }

5. Use a new CSS pseudo selector (like -moz-broken now works for broken images):
   OBJECT:-moz-missing-plugin {
     -moz-binding: url(chrome://plugin/default.xml)
   }

6. Use inline style with a new rule:
   <OBJECT style="-moz-default: url('http://server.com/get_plugin.xpi')">
   (this can be tested using the 'content' style)

Comment 6

[rubydoo123]

The style attribute has been deprecated in the XHTML side of things, so we don't 
want to use that path.

It may be useful to note that it would be up to the author to determine where 
the trigger is set. So, if the author determines that the 1st nested object is 
where the trigger should be, then we would be satisfying their needs. Not 
falling through would be appropriate in that respect. Granted, if the user had 
the appropriate plug-in listed in the next level object element may cause 
frustration in some cases.

However, at the point we make the decision to jump, don't we know the mime type? 
How much of a hit would it be to look at the plug-ins list to see if that mime 
type has been mapped and then launch that mapped plug-in? Would that be the 
correct thing to do?

Comment 7

[Arun Ranganathan]

I suspect we are creating imaginary bogey men here.  In the EMBED tag, if you
wished to have similar nested content, you'd see three default plugins (would
you not?) and there'd be 3 separate processes to get the shared library that we
need.  Am I wrong about this? 
Comment for Dennis Antrushin: On every major site, codebase is used in
conjunction with the object tag to specify where the ActiveX control lives (in a
signed CAB file).  For an example, see www.macromedia.com . 

Comment 8

[Peter Lubczynski]

Hm...I wonder if we could leverage View | Page Info's Media tab which seems to
also list plugins.

Comment 9

[Arun Ranganathan]

To add to the discussion on whether to use "codebase" as the paramount trigger
to find a plugin that isn't on the desktop, here's some quotes on the matter
from a W3C cognoscenti.  W3C was *specifically* asked whether codebase is a
viable attribute to be used in conjunction with object tag to find plugins:

"I did try to find an answer, but regretfully I don't really have
a clear answer.  In other words, we don't really have a platform-
independent plug-in API yet.  That's what "Component Extension (CX)
API requirements" [1] are going to address to some extent, but we
don't have the specification for that yet.

For better or worse, "object" was designed to accommodate the existing
practice of 1996-1997.  The HTML 4 spec lists several examples to
point to plug-ins, but that depends on the type of plug-ins.  So in
reality, Sun defines it for Java plug-ins, Microsoft defines it for
Active X components and Netscape defines it for Netscape plug-ins,
and so forth.

So the "classid" attribute may be used to specify the location of
an object's implementation, but that usage depends on the type of
plug-ins.  That's unfortunate, but that's what the spec says - sorry.

[1] http://www.w3.org/TR/CX" 

I vote: let's use codebase for NPAPI plugins.  

Comment 10

[Chris Nalls]

cc:chrisn

Comment 11

[rubydoo123]

this is the bug that is to be used for implementing the default plug-in support
in the object tag.

Comment 12

[Peter Lubczynski]

Attachment: patch for codebase

This patch enables the default plugin to be shown for OBJECT tags that have a
CODEBASE attribute. The Windows default plugin already treats this CODEBASE
like a PLUGINURL.

Comment 13

[av (gone)]

Is there any reason you use nsIDOMElement for getting the codebase attribute?
Why not to use |nsIPluginTagInfo|, I think you can qi |nsIPluginTagInfo2| of
|aOwner| for it. Also, rather than checking its length for being < 1 you can
just see if |GetAttribute| succeeded.

Comment 14

[Peter Lubczynski]

I used nsIDOMElement instead of |GetAttribute| because it has much less
overhead. |GetAttribute| builds the whole attribute/parameter array from the DOM
and there's no need to do that if we don't need to show any plugin.

Comment 15

[av (gone)]

Comment on attachment 84224 [details] [diff] [review]
patch for codebase

Makes sense, r=av

Comment 16

[Patrick C. Beard]

Comment on attachment 84224 [details] [diff] [review]
patch for codebase

Consider using nsIDOMElement::HasAttribute() instead of GetAttribute() to avoid
doing the string copy. Or at least to guard doing the copy. Other than that,
sr=beard

Comment 17

[scottputterman]

removing adt1.0.0 per discussion with peterl.  Let's get this on the trunk and
get some testing and then add the adt1.0.0 when it's ready to land on the branch.

Comment 18

[Christine Wozniak]

Adding custrtm-; no impact on customization team.

Comment 19

[Peter Lubczynski]

Attachment: update patch based on comments

Comment 20

[Peter Lubczynski]

patch in trunk, marking FIXED.

Comment 21

[Jaime Rodriguez, Jr.]

shrir - can you verify this on the trunk? should you have any questions, pls
ping peterl.

Comment 22

[shrirang khanzode]

Attachment: testcase

Comment 23

[shrirang khanzode]

another test ( with java xpi). this test works great on both win and linux.

http://jazz/users/shrir/publish/objjava.html

Issue:

[This totally might be an ftp.netscape.com issue..not sure]. 
ok, tested on windows and linux. am seeing something weird. With PFS ON...I see 
an alert dialog ( will attach next) for missing xpi on winNT. 

On linux, the flash xpi dialog comes up.( with the flash test attached earlier) 
Clicking OK to install flash in the first test attached above (on linux) opens 
up a new blank window which remains open and the throbber keeps spinning even 
after flash is installed. 
After flash is installed on linux..I checked 'about:plugins' ..the plugin was 
not listed. It was physically present inside the plugins folder but is just not 
picked up for use by the browser ( might be another issue).


With PFS OFF...this thing works well..no issue seen. 

Comment 24

[shrirang khanzode]

ughhhh....forget the second paragraph completely about linux. MY fault !!

I need to write up a seperate test to test flash xpi on linux. The only issue I 
see is the alert dialog(image coming up)

Comment 25

[shrirang khanzode]

Attachment: screenshot

Comment 26

[shrirang khanzode]

linux object test (flash)
http://jazz/users/shrir/publish/Linuxobjtest.html

Comment 27

[scottputterman]

adding adt1.0.1+.  Please check into the branch after getting drivers approval.

Comment 28

[shrirang khanzode]

this bug as such is fixed. I can now access the default plugin by using an 
object tag. 

Comment 29

[Randell Jesup [:jesup] (needinfo me)]

Comment on attachment 85672 [details] [diff] [review]
update patch based on comments

Approved for 1.0 branch.  Please remove mozilla1.0.1+ when it's fixed and add
fixed1.0.1

Comment 30

[Peter Lubczynski]

patch landed on 1.0 branch

Comment 31

[shrirang khanzode]

verif on branch 0718 builds.

Comment 32

[Peter K. Sheerin]

I don't mean to disrupt the decision that's already been made (and am thus 
leaving the status as is), but I'm not convinced codebase is the appropriate 
tag here, since it's supposed to specify a URL that can be used as a base path 
for other attributes.

[from the html 4.01 spec:]

codebase: This attribute specifies the base path used to resolve relative URIs 
specified by the classid, data, and archive attributes. When absent, its 
default value is the base URI of the current document. 

classid: This attribute may be used to specify the location of an object's 
implementation via a URI. It may be used together with, or as an alternative 
to the data attribute, depending on the type of object involved.

codetype: This attribute specifies the content type of data expected when 
downloading the object specified by classid. This attribute is optional but 
recommended when classid is specified since it allows the user agent to avoid 
loading information for unsupported content types. When absent, it defaults to 
the value of the type attribute. 

Given this, shouldn't classid be used instead, with the URI that points to the 
xpi file? Then codebase can be used as a reference path for other attributes 
and codetype can be used to make it clear what the mime type is for the file 
it references, so that you could support multiple types of distributions in 
the future, without making the assumption that a plugin archive will always be 
xpi/zip. 

Opera is working on adding support for plug-ins with the <object> tag--perhaps 
some effort should be made to ensure both implementations are compatible and 
reasonably follow the HTML spec?

And I'm surprised that no items in this bug report mention 
http://www.mozilla.org/projects/plugins/plugin-identifier.html, which suggests 
something like this:

<object classid="@mycompany.com/MyApplication,version=5.01" data="myfile.typ" 
codebase="http://myurl.com/myplugin/myplugin.xpi" type="application/x-myapp"> 
</object>

Comment 33

[Peter K. Sheerin]

Here's a question I haven't seen raised before. If the data attribute is used 
with a simple file name or relative URI to reference the content to be loaded, 
and codebase has a value that is used to locate the plug-in, then doesn't the 
HTML spec require that the plug-in look for the data file on that site, not 
the relative path based on the document?

In the example given, assume it is on a page located on myserver.com/content/:

<object type="application/xyz" data="myfile.xyz"
codebase="http://hereisxyz.com/myxyz.xpi"><param id="myparam" name="XYZ-Ident"
value="myXYXIdent"/></object>

The intent expressed in the proposal is that myfile.xyz come from 
myserver.com/content/, yet the HTML spec says it should come from 
hereisxyz.com.

Is this a problem, or am I misinterpreting the spec? If it is a problem, 
wouldn't putting the absolulte path to the .xpi package in the classid 
attribute solve the problem?