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

VERIFIED FIXED in mozilla1.0.1

Status

()

Core
Plug-ins
P2
normal
VERIFIED FIXED
16 years ago
16 years ago

People

(Reporter: Arun Ranganathan, Assigned: Peter Lubczynski)

Tracking

Trunk
mozilla1.0.1
x86
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [ADT1 RTM] [PL RTM],custrtm-)

Attachments

(3 attachments, 1 obsolete attachment)

(Reporter)

Description

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

Comment 1

16 years ago
Nominating nsbeta1 per discussion with beppe.  Add "+" as you see fit.
Keywords: nsbeta1
Priority: -- → P2
Target Milestone: --- → mozilla1.0

Comment 2

16 years ago
peterl
Assignee: beppe → peterl

Comment 3

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

16 years ago
moving this out to 1.1, planning needs to take place before this can happen
Keywords: nsbeta1 → nsbeta1-
Target Milestone: mozilla1.0 → mozilla1.1alpha

Comment 5

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

16 years ago
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?
(Reporter)

Comment 7

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

16 years ago
Hm...I wonder if we could leverage View | Page Info's Media tab which seems to
also list plugins.
(Reporter)

Comment 9

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

16 years ago
cc:chrisn

Updated

16 years ago
Keywords: nsbeta1- → nsbeta1
Target Milestone: mozilla1.1alpha → ---

Comment 11

16 years ago
this is the bug that is to be used for implementing the default plug-in support
in the object tag.
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [ADT1+] [PL RTM]
Target Milestone: --- → mozilla1.0

Comment 12

16 years ago
Created attachment 84224 [details] [diff] [review]
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

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

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

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

Makes sense, r=av
Attachment #84224 - Flags: review+

Updated

16 years ago
Attachment #84224 - Flags: superreview+

Comment 16

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

Updated

16 years ago
Keywords: adt1.0.0
Whiteboard: [ADT1+] [PL RTM] → [ADT1+ RTM] [PL RTM]

Comment 17

16 years ago
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.
Keywords: adt1.0.0
Whiteboard: [ADT1+ RTM] [PL RTM] → [ADT1 RTM] [PL RTM]

Comment 18

16 years ago
Adding custrtm-; no impact on customization team.

Updated

16 years ago
Whiteboard: [ADT1 RTM] [PL RTM] → [ADT1 RTM] [PL RTM],custrtm-

Comment 19

16 years ago
Created attachment 85672 [details] [diff] [review]
update patch based on comments
Attachment #84224 - Attachment is obsolete: true

Updated

16 years ago
Attachment #85672 - Flags: superreview+
Attachment #85672 - Flags: review+

Comment 20

16 years ago
patch in trunk, marking FIXED.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED

Updated

16 years ago
Keywords: adt1.0.1

Comment 21

16 years ago
shrir - can you verify this on the trunk? should you have any questions, pls
ping peterl.
Blocks: 143047

Comment 22

16 years ago
Created attachment 86810 [details]
testcase

Comment 23

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

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

16 years ago
Created attachment 86880 [details]
screenshot

Comment 26

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

Comment 27

16 years ago
adding adt1.0.1+.  Please check into the branch after getting drivers approval.
Keywords: adt1.0.1 → adt1.0.1+, mozilla1.0.1

Comment 28

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

Updated

16 years ago
Attachment #85672 - Flags: approval+
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

Updated

16 years ago
Keywords: mozilla1.0.1 → mozilla1.0.1+

Comment 30

16 years ago
patch landed on 1.0 branch
Keywords: mozilla1.0.1+ → fixed1.0.1
Target Milestone: mozilla1.0 → mozilla1.0.1

Comment 31

16 years ago
verif on branch 0718 builds.
Status: RESOLVED → VERIFIED
Keywords: fixed1.0.1 → verified1.0.1

Comment 32

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

16 years ago
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?
You need to log in before you can comment on or make changes to this bug.