The JavaSoft guys want to add a VERSION attribute to the object/applet/embed tags that allows the particular version of the Java VM to be specified. I think this needs to be done in a fairly general way, allowing not only the version of the JVM, but also the version of the plugin, the manufacturer, etc to be specified. The reason they want this is to facilitate going and getting the latest version of the Java Plugin if a particular applet needs some version-specific features. This relates to Alex Musil's proposal for smarter installation of plugins that don't involve dumping the user at the plugin page, but instead install automatically. I think we also want to think about how we might support applets that belong to different JVMs simultaneously. It should be possible to install the JavaSoft Java Plugin, and the Microsoft Java Plugin, making one be the default, but allowing an applet to specify exactly which one they need to run. Maybe this relates to the clsid stuff in bug 255180. More Object tag stuff...

Setting all current Open/Normal to M4.

per leger, assigning QA contacts to all open bugs without QA contacts according to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser

assigning Greg as QA contact

claudius,re-assigning some of Greg's open bugs to you.

Marked [ENH]. I suspect that Netscape engineering will not have the cycles to do this for now, but perhaps Sun contributors or someone else may? Andrei, recommend that we push this out beyond M11--maybe to M20 (later), realistically. If we have the cycles to do this, we should try to achieve this worthwhile goal by using standard attributes of HTML 4.0 (if possible) instead of by adding a proprietary extension. This is a general problem for browsers and plug-ins when multiple plug-ins can render the same content, and it would be best if there were a standard, cross-browser solution to the problem. Below are relevant excerpts from the specification. The problem: if I understand the below correctly, by "implementation of the object" they mean the specific code for this instance (e.g. a single applet) and all the attributes are specifying how to get this single instance. There doesn't seem to be any mention of specifying the location of the enabling code (the plug-in itself) that would run the instance. It's hard to believe that the HTML 4.0 specification completely overlooked the issue that an OBJECT may be renderable my multiple plug-ins, and that one may wish to specify a preference for one over the other and how to get it. How did Sun's Java Activator solve this problem? cc:ing drapeau@eng.sun.com for comment. http://www.w3.org/TR/REC-html40/struct/objects.html#h-13.3 classid = uri [CT] 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 = content-type [CI] 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. type = content-type [CI] This attribute specifies the content type for the data specified by data. This attribute is optional but recommended when data is specified since it allows the user agent to avoid loading information for unsupported content types. http://www.w3.org/TR/REC-html40/struct/objects.html#h-13.3.3 13.3.3 Global naming schemes for objects The location of an object's implementation is given by a URI. As we discussed in the introduction to URIs, the first segment of an absolute URI specifies the naming scheme used to transfer the data designated by the URI. For HTML documents, this scheme is frequently "http". Some applets might employ other naming schemes. For instance, when specifying a Java applet, authors may use URIs that begin with "java" and for ActiveX applets, authors may use "clsid". In the following example, we insert a Java applet into an HTML document. <P><OBJECT classid="java:program.start"> </OBJECT> By setting the codetype attribute, a user agent can decide whether to retrieve the Java application based on its ability to do so. <OBJECT codetype="application/java-archive" classid="java:program.start"> </OBJECT> Some rendering schemes require additional information to identify their implementation and must be told where to find that information. Authors may give path information to the object's implementation via the codebase attribute. <OBJECT codetype="application/java-archive" classid="java:program.start"> codebase="http://foooo.bar.com/java/myimplementation/" </OBJECT> The following example specifies (with the classid attribute) an ActiveX object via a URI that begins with the naming scheme "clsid". The data attribute locates the data to render (another clock). <P><OBJECT classid="clsid:663C8FEF-1EF9-11CF-A3DB-080036F12502" data="http://www.acme.com/ole/clock.stm"> This application is not supported. </OBJECT>

Pushing to Future, changing severity to "enhancement". Hopefully there is agreement that adding an additional attribute to OBJECT/APPLET is the wrong way. I think there may be precendent for a solution with ActiveX controls. It is possible to specify use of a *specific* handler by using the CLASSID attribute for OBJECT. I think this could have a direct mapping to XPCOM plugins. Would such a mechanism adequately address the problem described here?

this may be resolved with the use of the 'plid', please see bug 44973. Should this be duped to that bug?

marking as dup of 44973, versioning is not specified in the w3c spec, our current implementation plan to resolve versioning is through the plid *** This bug has been marked as a duplicate of 44973 ***

VERIFIED DUPE