178780 - Problems in using a standards compliant <object> tag that works in all browsers [for Java]

Status: RESOLVED WONTFIX

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

Description

[brent]

[Background: this bug report/feature request grows out of the final parts of
this discussion:
	http://bugzilla.mozilla.org/show_bug.cgi?id=108557

As per the request of [e-mail], who made comment #83 in the
above, I am filing a new bug report.

Here are some additional relevant bug reports:
	http://bugzilla.mozilla.org/show_bug.cgi?id=173140
	http://bugzilla.mozilla.org/show_bug.cgi?id=108557
]

Claim 1: a browser can only be said to support Java applets via the <object> tag
if it has the following characteristics:

	1) a single <object> tag (including <param> child tags) specifies everything

	2) it must support applet code being located inside a jar/zip file

	3) there must be a way to specify a particular JVM version to use

	4) it would be really nice if this JVM specification supported both dynamic
versioning (e.g. if a 1.3 JVM was specified but the user has a 1.4 JVM, then
that is OK and the 1.4 JVM will be used) and static versioning (the exact JVM
specified must be used); see http://java.sun.com/products/plugin/versions.html

	5) if a satisfactory JVM is not present, then the <object> tag will have an
attribute with a URL value that the user can download the JVM from

	6) the "scriptable" property of the applet must be specifiable

	7) archive caching must be specifiable (see
http://java.sun.com/j2se/1.3/docs/guide/misc/appletcaching.html)

	8) the html file must validate against the strict html 4.01 dtd
(http://www.w3.org/TR/html4/strict.dtd), as well as xhtml

	9) the same solution works under both IE and Moz
		--this means that hacks like inserting an <object> tag that works under
Mozilla as a child of an <object> tag that works under IE is NOT a solution, as
most developers will not bother with this ugly hassle -- there really should be
a single standard solution

Claim 2: Mozilla fails some of the above requirements (see discussion below).

If anyone can post an html fragment that shows ALL of the requirements in claim
1 in action and working, then I would be very grateful and I will gladly retract
claim 2.  Please do not post "baby code" examples that only have some of the
above in action, and merely assume that the rest work.  Consider this html
fragment as an indication of what is really needed:

	<object classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93"
codebase="http://java.sun.com/products/plugin/1.4/jinstall-14-win32.cab#Version=1,4,0,mn"
width="250" height="400" style="vertical-align: baseline;">
			<!-- Specify the Applet class to use: -->
		<param name="code" value="FastAnimationApplet.class">
		<param name="codebase" value="./">
		<param name="archive" value="./animationResources.jar">
			<!-- Specify other features about the Applet: -->
		<param name="type" value="application/x-java-applet;jpi-version=1.4">
		<param name="scriptable" value="false">
			<!-- Specify archive caching (see
http://java.sun.com/j2se/1.3/docs/guide/misc/appletcaching.html): -->
		<param name="cache_option" value="No">
		<param name="cache_archive" value="./animationResources.jar">
			<!-- Specify below stuff specific to the Applet in use: -->
		<param name="someName" value="someValue">
		<!-- etc etc -->
			<!-- Text to display if Java not supported: -->
		A Java applet should be here, but it could not be displayed.
		Possible causes include:
		<ul>
			<li>your browser does not support Java 2 SDK Standard Edition v 1.4.0</li>
			<li>Java support has been disabled</li>
			<li>an internal error occurred</li>
		</ul>
	</object>

I believe that this code satisfies all of the above conditions except for 9): it
only works in IE.  (Well, I have not exactly tested some of the conditions like
3) thru 7), and am simply trusting the documentation that they work; see:
	http://java.sun.com/j2se/1.4/docs/guide/plugin/developer_guide/using_tags.html
	http://java.sun.com/j2se/1.3/docs/guide/misc/appletcaching.html
	http://java.sun.com/products/plugin/versions.html
)
 
If I understand the discussion in earlier bug reports (e.g.
http://bugzilla.mozilla.org/show_bug.cgi?id=108557) correctly, the above does
not work in Moz because the classid used there acutally specifies an ActiveX
plugin, which Moz does not support.

OK.  So why doesn't Moz simply ignore classids (since it can't handle them) and
instead have the JVM simply be specified by adding a type attribute inside the
<object> tag like
	type="application/x-java-applet;jpi-version=1.4"
?  It would would be so nice if that were all it took to get stuff to work in
Moz.  IE seems to completely ignore type attributes, so there would be no
interference.

Instead, to get things to work in Moz, I found that not only do I need to add
the above type attribute, but I also need to rip out the classid attribute.
Other than that, it appears that EVERYTHING ELSE CAN STAY THE SAME.  (In
particular, you do not need to specify stuff like code/data and archive as
attributes in the <object> tag, which everybody else seems to want to do, but
can instead do it IE style as <param> tags; I suspect that this has nothing to
do with Moz but is because sun's AppletViewer class supports this, so as long as
it is launched then everything is fine.)  Here is a fragment that works in my
Moz 1.1 with my JDK 1.4.0_01:

	<object type="application/x-java-applet;jpi-version=1.4.0_01"
codebase="http://java.sun.com/products/plugin/1.4/jinstall-14-win32.cab#Version=1,4,0,mn"
width="250" height="400" style="vertical-align: baseline;">
			<!-- Specify the Applet class to use: -->
		<param name="code" value="FastAnimationApplet.class">
		<param name="codebase" value="./">
		<param name="archive" value="./animationResources.jar">
			<!-- Specify other features about the Applet: -->
		<param name="type" value="application/x-java-applet;jpi-version=1.4">
		<param name="scriptable" value="false">
			<!-- Specify archive caching (see
http://java.sun.com/j2se/1.3/docs/guide/misc/appletcaching.html): -->
		<param name="cache_option" value="No">
		<param name="cache_archive" value="./animationResources.jar">
			<!-- Specify below stuff specific to the Applet in use: -->
		<param name="someName" value="someValue">
		<!-- etc etc -->
			<!-- Text to display if Java not supported: -->
		A Java applet should be here, but it could not be displayed.
		Possible causes include:
		<ul>
			<li>your browser does not support Java 2 SDK Standard Edition v 1.4.0</li>
			<li>Java support has been disabled</li>
			<li>an internal error occurred</li>
		</ul>
	</object>

Does anyone know if condition 5) of claim 1 is satisfied by Moz (i.e. that it
will goto
	http://java.sun.com/products/plugin/1.4/jinstall-14-win32.cab#Version=1,4,0,mn
and download the plugin if necessary)?  (I suspect NOT, based on Peter
Lubczynski's comments below.)

And that conditions 6) ("scriptable") and 7) (archive caching) are supported? 
(Probably are, as long as Sun's Java plugin gets launched, as it and not the
browser is what will use the <param> tags.)

Also, for condition 4),
	http://java.sun.com/products/plugin/versions.html
indicates that with the old embed tag dynamic versioning and static versioning
are achieved by using the type "application/x-java-applet;version=..." and
"application/x-java-applet;jpi-version=..." respectively.  Does this hold true
here as well?  It does not seem to for me: when I tried using just
"application/x-java-applet;version=..." it asked me to download a plugin; this
is bad, as dynamic versioning is what is typically most useful.

Regardless, the ripping out of the classid has the disastrous effect that it no
longer works in IE.  This is completely unsatisfactory!

If Moz would ignore the classid in this case (since it does not support it) and
instead use the type attribute (which IE seems to ignore) then I believe that
both Moz and IE could be gotten to work with a single <object> tag.

Below, for convenience, I have include the feedback that others in
	http://bugzilla.mozilla.org/show_bug.cgi?id=108557
have given to my above proposal (my comments back are in braces):

	------- Additional Comment #81 From Boris Zbarsky 2002-10-08 23:42 -------

	Looking over nsObjectFrame::Reflow, it looks like Brent's suggestion (which I
	wholeheartedly support, btw, unless someone has a _really_ good reason why we
	should not implement it) would not be that hard to do.  We'd just need to make
	the "not java object or internal widget and we have no ActiveX handler" case
	fall through to "no classid attribute" code...

[That is encouraging.]

	------- Additional Comments From [e-mail]  2002-11-06 12:36
-------

	open a new bug for your suggestion. This bug is about removing a hard-coded
	constant and has been fixed for a long time.

	However, I don't see the problem of using the same tag. The following markup
	gets Java easily working in both browsers:
	http://www.mozilla.org/quality/browser/front-end/testcases/oji/objecttest1.html

	<object codebase="." classid="java:JitterText.class" width=400 height=80
	align=left border=0>
		<param name=BGCOLOR value="000000">
		<param name=TEXTCOLOR value="FF0000">
		<param name=TEXT value="OJITesting!">
		<param name=SPEED value="250">
		<param name=RANDOMCOLOR value=1>
	</object>

[The above is an inadequate example: it does NOT show characteristics 2--7 in
action.  OK, I bet that it would be easy to get characteristics 2 & 6--7 to
work.  But the tough stuff is the JVM version info and how to download the
plugin if the user does not have it (characteristics 3--5).  Show me that in
action in an html fragment that works in both browsers and I will be happy.]

	It even works with the TYPE attribute.

[Are you referring to the code fragment that you posted in Comment #66?  Namely,
	<object type="application/x-java-applet;jpi-version=1.4.0_01"
codebase="http://www.mozilla.org/quality/browser/front-end/testcases/oji" 
	code="JitterText.class" width=150 height=80 align=left vspace=20>
	<param name=BGCOLOR value="000000">
	<param name=TEXTCOLOR value="FF0000">
	<param name=TEXT value="OJITesting!">
	<param name=SPEED value="250">
	<param name=RANDOMCOLOR value=1>
	</object>
]

	If Gecko just ignored the CLASSID attribute, we'd run into problems in
	determining what CODEBASE is used for.

[I don't understand the above comment: the html fragement that I posted above
that works in Moz has no classid at all and works.  Or do you mean that there
are other cases besides Java applets specified via <object> tags where Moz DOES
use classid info, so the logic cannot be as simple as to turn off all classid
support?]

	Microsoft in the ActiveX world uses
	CODEBASE to refer to where to download the Java plugin CAB installer while the
	W3C spec (and Gecko) understand CODEBASE to meam the base URL for the 'code'.

[And what is the w3c's method of specifying an installer url?

Furthermore, the w3c spec for codebase is
	"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."
So codebase indeed applies to classid, which in turn means
	"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."
Is the Java plugin not a reasonable interpretation of "an object's implementation"?

Also, while the code attribute may work, I do not see it mentioned in the w3c
spec at
	http://www.w3.org/TR/html401/struct/objects.html
except for use in the deprecated <applet> tag.
]

Comment 1

[Matthias Versen [:Matti]]

.

Comment 2

[Boris Zbarsky [:bzbarsky]]

this is plugins

Comment 3

[Boris Zbarsky [:bzbarsky]]

.

Comment 4

[brent]

WARNING: for the type attribute, it is generally not a good idea to use
	application/x-java-applet;jpi-version=...
as I did in my original posting, as that is static versioning.  What you
typically want is dynamic versioning, as in the slightly simpler
	application/x-java-applet;version=...
see
	http://java.sun.com/products/plugin/versions.html

Also, if this issue ever gets resolved, Sun needs to be notified to really
update their applet documentation.

Comment 5

[rubydoo123]

Let me try and answer some of the points you mention.

1) a single <object> tag (including <param> child tags) specifies everything

The object element is meant to be constructed where it has the flexibility to
resolve several oddities within the web community. Nowhere does it state in the
specification that one object element must be used, that is simply not the case.
The object element was and is designed to be nested. Each nested object can
therefore function or be processed by differing user agents or applications.
Now, you may want to only use one object element, but that is not a standards
requirement.

2) it must support applet code being located inside a jar/zip file
The author would use the archive attribute to specify jar files, it can be
either a single reference or it can be a comma separated reference.

3) there must be a way to specify a particular JVM version to use
You can specify the version via the type attriubte, as directed by Sun, please
see: http://java.sun.com/products/plugin/versions.html 

"Only version is used in the type attribute with EMBED tag; e.g.,
type="application/x-java-applet;version=1.4"

This is another form of dynamic versioning."

This versioning can be used within the Object element as well.

4) it would be really nice if this JVM specification supported both dynamic
versioning (e.g. if a 1.3 JVM was specified but the user has a 1.4 JVM, then
that is OK and the 1.4 JVM will be used) and static versioning (the exact JVM
specified must be used); see http://java.sun.com/products/plugin/versions.html

This should be opened in another bug report and set as an enhancement request

5) if a satisfactory JVM is not present, then the <object> tag will have an
attribute with a URL value that the user can download the JVM from
This is an excellent use of the param element. In the case of Netscape, the
pluginurl value could be used. How other user agents handle this request is up
to them.

The W3C specification does not define how user agents provide this within the
element itself. Rather, the specification recommends that the author provide a
nested alternate text that could be used to point the user to the location. For
example, the author could provide a link to the location where the user can
download the data. Having the data download automatically is not a function of
the specification, rather it was an added feature included by the user agents. 

6) the "scriptable" property of the applet must be specifiable
The W3C specification does not define this "feature" to be accessible via the
object element. Rather, since this is specific to the applet and the handler
that processes applets, the appropriate method would be to pass this information
via the param element name/value pair. This param name/value pair would be
passed to the handler (we already pass all param values to the handler) and the
handler must be able to process that information. This should be a feature
request to Sun to support the appropriate param name/value pair. The browser
would only react to the handler and not necessarily perform any function or
process on the applet.

7) archive caching must be specifiable (see
http://java.sun.com/j2se/1.3/docs/guide/misc/appletcaching.html)
This is a new feature request and should be reported in a separate bug report.
The request is that the user agent filter two new param name/value pairs created
by Sun (<PARAM NAME="cache_option" VALUE="..."> <PARAM NAME="cache_archive"
VALUE="...">). The discussion would also need to resolve usage, processing and
destruction of the applet data. This is clearly not a requirement, rather a new
feature request.

8) the html file must validate against the strict html 4.01 dtd
(http://www.w3.org/TR/html4/strict.dtd), as well as xhtml
This is clearly an author issue and not a user agent issue. The author is the
one who chooses the element and attributes. Our parsing agent recognizes the
object element and the param element.

9) the same solution works under both IE and Moz
As I stated in item number 1, this is not a standards compliant behavior. Each
user agent has the ability to provide additional support as they feel
appropriate. IE utilizes the classid attribute to point to data via the
registry. We utilize the data and type attributes. The issue I believe that
comes into play is when codebase is included within the object element. From the
Netscape usage, codebase is used to define the base location for the object
data. IE usage is to point to the cab files that are needed. If a particular
object element has the construct of this:
<object data="foo" type="application/foo" classid="foo" codebase="foo">

How would IE, Opera or Netscape know whether the content of codebase is the base
URL or a pointer for the cab files? We wouldn't without a lot of analysis. That
is not feasible. The 4.x family of HTML specifications left the object element
too open to force a single usage object.

The XHTML 2.0 specification has refined the definition to the point where it
could be possible to use one object element. Until such time that authors and
user agents support that model, then the need to have nested object elements
will be the case.

Comment 6

[brent]

>>1) a single <object> tag (including <param> child tags) specifies everything

>The object element ... was and is designed to be nested ... Now, you may want
to only use one object element, but that is not a standards requirement.

I never claimed that nested object elements violate the standard.

But I DO maintain that there ought to be one "standard" way of specifying an
applet, a way that gets by with a single object tag.  My claim is that most
developers are not going to go thru the hassle of oppressive nested schemes.  If
it doesn't work in a way that is fairly compatible with IE (as my proposal
trivially would be) then they will simply ignore supporting Mozilla and its way
of doing things.  Imagine if developers had to write nested img tags in order to
get images to display in both Moz and IE; guess how many would do that?

You really need to hear this feedback from the people (developers) who are going
to make or break Mozilla.  Hint: they do not want to hear that they have to
write a lot of custom code to support it.


>>2) it must support applet code being located inside a jar/zip file

> ... use the archive attribute to specify jar files

The examples for both IE and Mozilla in my original post use a param element to
do this; seems to work in both browsers.


>>3) there must be a way to specify a particular JVM version to use

>You can specify the version via the type attriubte ...

Same comment as above.


>>4) it would be really nice if this JVM specification supported both dynamic
versioning ...

>This should be opened in another bug report and set as an enhancement request

I do not know if it deserves a new bug report as this point, as I have not
tested it.  If the type attribute behaves the same in <object> as it is supposed
to for <embed> then everything is OK.  If anyone has knowledge here, please post!


>>5) if a satisfactory JVM is not present, then the <object> tag will have an
attribute with a URL value that the user can download the JVM from

>This is an excellent use of the param element. In the case of Netscape, the
pluginurl value could be used. How other user agents handle this request is up
to them.

Could you please give me an example of how to do this?  And point me to some
documentation somewhere?  I have never stumbled across that before.

>The W3C specification does not define how user agents provide this ...

Let us hope that it is defined in a standard way in the future.


>>6) the "scriptable" property of the applet must be specifiable

> ... the appropriate method would be to pass this information via the param
element name/value pair ... (we already pass all param values to the handler)

I -suspect- that it already does work, assuming that Sun's java plugin ever gets
launched in the first place, for the reason you specify above.  I have not
specificly tested this myself, however.  Also, I did not mean to suggest that it
is currently unsupported, just that it is something that must be.


>>7) archive caching must be specifiable (see
http://java.sun.com/j2se/1.3/docs/guide/misc/appletcaching.html)

>This is a new feature request and should be reported in a separate bug report ...

As with the "scriptable" property, I -suspect- that it already does work,
assuming that Sun's java plugin ever gets launched in the first place, since
that plugin should have access to all the param element name-value pairs
automaticly, no?  Again, I have not specificly tested this myself, and I did not
mean to suggest that it is currently unsupported, just that it is something that
must be.


>>9) the same solution works under both IE and Moz

>As I stated in item number 1, this is not a standards compliant behavior. Each
user agent has the ability to provide additional support as they feel appropriate.

That is theoretically correct.  However, in practice, one of the worst things to
ever happen to the web is all the **** that developers have to go thru to get
really common stuff to work on the different browsers.  I argued in the
beginning that developers hate this with a passion.  Mozilla currently does not
have the market share to adopt an attitude here.  People will just not support you.

>The issue I believe that comes into play is when codebase is included within
the object element. From the Netscape usage, codebase is used to define the base
location for the object data. IE usage is to point to the cab files that are
needed. If a particular object element has the construct of this: <object
data="foo" type="application/foo" classid="foo" codebase="foo">
How would IE, Opera or Netscape know whether the content of codebase is the base
URL or a pointer for the cab files? We wouldn't without a lot of analysis.

Would the analysis be all that difficult?  My original proposal was that if the
object tag's type signals a java applet, then you should ignore the classid
attribute, so why not ignore any codebase attribute as well?  (Hmm, while I
think that the analysis should be fairly trivial, the real problem is that since
you already have decided on one meaning, changing it now would impact people who
have done things the current way.)

Incidentally, you know how IE gets the codebase for the actual java code (as
opposed to the java plugin) specified?  Answer: they use a parameter named
codebase in a param tag.  For example,
	<param name="codebase" value="./">
I -think- that Mozilla implicitly supports this to, since (as with scriptable
and archive caching) it should pass the param tag info to sun's java plugin
which does support it.  So, your current support of codebase as an attribute
inside object is actually redundant.

>The 4.x family of HTML specifications left the object element too open to force
a single usage object.

Badly written specs, the source of much woe.

>The XHTML 2.0 specification has refined the definition to the point where it
could be possible to use one object element.

It would be miraculous!

Has that spec been finalized, and could you post a url to it?

>Until such time that authors and user agents support that model, then the need
to have nested object elements will be the case

When will Moz support it?  And do you know about when IE will support it?

Comment 7

[rubydoo123]

Hi Brent: I can send you the object module to review for XHTML 2.0. I would
appreciate any feedback and input. The spec will be under internal (W3C HTML WG)
review in a couple of weeks. So of I can incorporate any isseus that you see,
then great.

I still have to add a few notes on how user agents should or may handle certain
situations such as when the author neglects to include nested alternate text. 

Netscape, IE and Opera will all eventually support XHTML 2.0, I cannot provide
any dates at this point as to when that would happen.

Comment 8

[Peter Lubczynski]

You are asking for too much. Mozilla has no support for "upgrading" plugins
based on version like IE. The only reason this works now is that the version for
the plugin is encoded in the mime type and when the browser doesn't see that
mime type, it prompts the user to download. You'll need to use JS or nested
object tags to ensure you are using the right version of Java if you want to use
one tag, otherwise all other conditions are currently met with one tag when not
using ActiveX syntax.

IE is not standards compliant with the OBJECT tag because CODEBASE is used to
mean something else. IE 6 prompts me to download an ActiveX control from the
wrong location when viewing these tests:
http://www.mozilla.org/quality/browser/front-end/testcases/oji/objtest1.html
Moz is standards compliant so CODEBASE points to the base url for where to get
the Java code.

So in order to get around this problem, we would not only need to ignore
CLASSID, but also substitute the PARAM value for CODEBSE instead of using the
attribute. Furthermore, we might have to change the DOM to reflect this because
Java has direct access.

Comment 9

[rubydoo123]

reassign

Comment 10

[Mike Cowperthwaite]

Some comments on Brent's requests:

There is *some* support in the works for auto-upgrading a plugin from Mozilla;
see bug 167601.  (Also 180411, which is tangentially related.)  But as stated
above, the alternate use of 'codebase' by the ActiveX OBJECT tag completely
precludes a single OBJECT tag being used in both browsers -- at least, one that
relies on the ActiveX code.

IE is the one that's not standard, so complain to them, and to Sun.  However,
it's fair to note that IE on the Macintosh (a much nicer browser than the
Windows thing) is supposed to be adding the same kind of emulation for the
ActiveX tag that Mozilla once had (and that Opera currently has, despite my
recommendation that they drop it).

Another reason to avoid the ActiveX tag is that if an IE user has opted to
disable Java in his system, this tag will nonetheless invoke the applet; IE
will only suppress the applet if ActiveX controls have been disabled.

There is a basic problem with the MIME versioning system, which is that it ties
directly to the Sun Java, and may fail for Java implementations from other
vendors (IBM, perhaps Blackdown).  Unless those Javas also associate their
plugin with the various versioned x-java-applet types, they won't get
invoked.  If your page happens to be used by a Linux person running IBM Java,
she won't be pleased when you try to download a Sun plugin, particularly if
you force that plugin to be the Windows version.

Similarly, relying on the Sun-specific 'scriptable' and 'cache_xxx' parameters
ties you in to using the Sun plug-in.  Also, Opera instantiates its own JRE and
does not interface to the plug-in, so those parameters will never work with
Opera. 

There is a recommendation for dealing with these tags up at Netscape, see:
http://devedge.netscape.com/viewsource/2002/markup-and-plugins/#obj-java
and also
http://devedge.netscape.com/library/manuals/2002/plugin/1.0/intro.html#1001793

The first article shows simple Javascript to generate a tag dynamically,
testing on 'window.ActiveXObject' to generate either the ActiveX tag or the
standard tag.  The 'standard' tag promulgated in the article uses the MIME
type plus <PARAM name="code" value="appletname">, rather than
classid="java:appletname"; this is problematic for some other browsers,
but does in fact work OK for Mozilla and Netscape 4, as well as Opera 6&7,
at least under Windows but probably for Linux, and MacOS X with the MRJPlugin.

The classid="java:appletname" form of the tag appears in the HTML 4 spec, so
it is as close to standard as we're likely to find at the moment.  However,
its support in Netscape 4 and IE 6 is broken and *always* uses the brower's "native" Java -- that is, the 1.1.x bundled with Netscape, and the 1.1.x
that Microsoft provides, respectively.  It's no good for Java applets.

Regardless, that tag is very widely supported by every other browser that's
complete (OmniWeb and Konqueror being two notable in-development exceptions;
I haven't had a chance to test with Safari or iCab yet.)

Finally:  There is one form of <OBJECT> I know of that will load an applet,
using the Java plugin, in IE4-6, Opera 5-7, Netscape 4, and Gecko.
This tag is NONSTANDARD, but looks like:

  <OBJECT code="TunePlayer.class"
    type="application/x-java-applet" codebase="classes/"
    width="200" height="75">
    <PARAM name="clip" value="tunes/EasyWind.mp3" />
  </OBJECT>

The 'code' attribute is the nonstandard part, but for some reason is widely
supported.  I've tested this in all the above browsers under Windows; I do not
know how well it works under Mac or Linux versions of these browsers, but
because it's basically a variation on the EMBED tag, any browser with a Java
plugin associated with "applicaton/x-java-applet" ought to load the applet.

Comment 11

[brent]

[e-mail] writes:

>IE is the one that's not standard, so complain to them, and to Sun.

I too have concluded that The Beast is the one at fault here, not following the
W3 standards and doing windoze-centric stuff.  Do you know where to complain to
IE?  Is it worth it and and do they actually listen?


>There is a basic problem with the MIME versioning system, which is that it ties
>directly to the Sun Java, and may fail for Java implementations from other
>vendors (IBM, perhaps Blackdown).  Unless those Javas also associate their
>plugin with the various versioned x-java-applet types, they won't get
>invoked.

I would assume that those other Javas must do the above association, right?  If
you look at the MIME names, there is nothing sun-specific in the names (e.g.
"application/x-java-applet;jpi-version=1.4.1_01") themselves.  And even if there
were, it would not stop them from intercepting those requests.


>Similarly, relying on the Sun-specific 'scriptable' and 'cache_xxx' parameters
>ties you in to using the Sun plug-in.

Well, they are probably ignored by other JVMs -- but they should not cause them
to crash.


>There is a recommendation for dealing with these tags up at Netscape, see:
>http://devedge.netscape.com/viewsource/2002/markup-and-plugins/#obj-java
>and also
>http://devedge.netscape.com/library/manuals/2002/plugin/1.0/intro.html#1001793

The first article is excellent; the guy who wrote it knows his stuff.

I was thinking of doing something similar, except that instead of javascript,
writing a jsp custom tag that generates the appropriate <object> tag depending
on the browser.  Your html code would be much conciser and clearer.  The
downside is that not you need a servlet server.


>The classid="java:appletname" form of the tag appears in the HTML 4 spec, so
>it is as close to standard as we're likely to find at the moment.  However,
>its support in Netscape 4 and IE 6 is broken and *always* uses the brower's
"native" Java --
>that is, the 1.1.x bundled with Netscape, and the 1.1.x
>that Microsoft provides, respectively.  It's no good for Java applets.

Right.  It is broken.

It is extremely annoying that even if you have sun's java plugin installed, IE
will never use it for java applets if they are specified in an <object> tag, but
only if they are specified in an <applet> tag.

For this reason, I have given up on web standards compliance when dealing with
applets and simply use the deprecated <applet> tag.

Beth Epperson (see also Additional Comment #7) has told me that the xhtml 2.0
spec should be defined carefully enough this time around that conflicts on the
meaning of things like codebase etc will not be possible; see
	http://www.w3.org/TR/2003/WD-xhtml2-20030131/mod-object.html#s_objectmodule

Once xhtml 2.0 is out and supported by IE and Mozilla, then I will switch back
to using <object>.  But it is hopeless (unless use dynamic tricks like above)
till then.


>Finally:  There is one form of <OBJECT> I know of that will load an applet,
>using the Java plugin, in IE4-6, Opera 5-7, Netscape 4, and Gecko.
>This tag is NONSTANDARD...

Which is why I am very nervous about using it; the rug could get pulled out from
you at any time.

Comment 12

[Magnus.Kessler]

The mime-type based method described in the article 
(http://devedge.netscape.com/viewsource/2002/markup-and-plugins/#obj-java) does 
actually work on IE as well, allthough it needs some help. 
 
The Sun java plugin unfortunately does not register a mime-type in the windows registry but 
rather relies on the ActiveX class id. I came across this the other day when I looke why flash 
movies would play without the class id. 
 
The "application/x-java-applet" (and similar versioned mime-types) should be registered under 
"HKEY_LOCAL_MACHINE\MIME\Database\Content Type". A mime entry here needs to have a 
CLSID key associated with it, which for the java plugin should have the value  
{8AD9C840-044e-11D1-B3E9-00805F499D93} (including the curly braces). 
 
Afer adding this entry to the registry IE is capable of launching an applet via an <object> tag 
without specifying the ActiveX classid in the HTML page. 
 
Maybe we should complain to Sun to include the setting of the registry keys into their plugin 
installer. Then all we need to do is somehow eradicate the thousands of bad examples on the 
web which use <object> with the classid and we are done: cross-browser without having to 
change a single line of code in either IE or Mozilla :) 
 
http://msdn.microsoft.com/workshop/components/activex/registration.asp describes the 
recommended way of registering ActiveX controls and associating them with mime-types. 
 
For what it's worth, I believe Mozilla should just ignore ActiveX classid's and start an 
appropriate plugin based on a mime-type (and should take the <parameter> section into 
account as well). This is still better than the current situation where it just silently fails. 

Comment 13

[Mike Cowperthwaite]

Brent:

>> Similarly, relying on the Sun-specific 'scriptable' and 'cache_xxx'
>> parameters ties you in to using the Sun plug-in.
>
> Well, they are probably ignored by other JVMs -- but they should not cause
> them to crash.

Except that 'cache_archive' is specified to be mutually exclusive from
'archive' -- you're not supposed to list the same archive filename in both
parameters.  If the browser or plug-in doesn't handle 'cache_archive',
the applet won't load.


Magnus.Kessler:

> Afer adding this entry to the registry IE is capable of launching an applet
> via an <object> tag without specifying the ActiveX classid in the HTML
> page.

Almost -- I tried this, and found that IE ignores 'archive' and 'codebase'
when it parses the tag.  This is similar to its handling of
'classid="java:appletname"' -- if you need to specify a codebase, you're
hosed.


FWIW, I've followed up on the three OBJECT tag formats in Safari/Konqueror:

classid="java:appletname"
  -- not currently supported; I've got an RFE in at KDE's bugzilla,
     and was told that this support is in progress.

type="application/java" / <PARAM name="code" value="appletname">
  -- works for KHTML right now

type="application/java" code="appletname"  [nonstandard]
  -- not supported by KHTML, and probably just as well

Comment 14

[Magnus.Kessler]

mcow: 
 
> Almost -- I tried this, and found that IE ignores 'archive' and 'codebase' 
> when it parses the tag.  This is similar to its handling of 
> 'classid="java:appletname"' -- if you need to specify a codebase, you're 
> hosed. 
 
It does however know about the corresponding <param> tags. This is what works for me: 
 
<object type="application/x-java-applet" width="200" height="200" id="myapplet"> 
	<param name="code" value="MyApplet"/> 
	<param name="codebase" value="."/> 
	<param name="archive" value="MyApplet.jar"/> 
</object> 
 
You can use all the parameters supported by the java plugin, see Sun documentation for 
supported parameters: 
http://java.sun.com/j2se/1.4.1/docs/guide/plugin/developer_guide/contents.html, especially 
chapter 8 for alternatives to archive. In light of what we are discussing here, the document 
needs some updates though ;) 
 

Comment 15

[Arun Ranganathan]

I'm glad that my article helps:
http://devedge.netscape.com/viewsource/2002/markup-and-plugins/ .  While I'm on
the subject, let me put in a quick plug for DevEdge -- we've completely
relaunched with a sleek web-standards based design: http://devedge.netscape.com/

In Comment 12 , M. Kessler suggests that the MIME type based way works for IE
with some registry tweaking.  VERY interesting.  We have weekly conference calls
with Sun about the OJI layer and stuff and I'm cc'ing someone who can maybe get
the ball rolling on Sun cleanly declaring a MIME type that is valid for IE as well.

This is a good bug and goes to the core of one of my pet issues: ensuring that
we have true standards compliance with object element -- the world of
embed/applet is slowly going away and we have to ensure viable standards
compliant alternatives.

Comment 16

[Magnus.Kessler]

Just for the record. My investigation into this issue a couple of weeks ago was triggered by the  
article on alistapart: http://www.alistapart.com/stories/flashsatay/ . Here the author also  
strips down the legacy ActiveX object tag until it is useable in both Mozilla and IE. He even has  
got a (flash specific) solution for the plugin update problem. 

Comment 17

[Mike Cowperthwaite]

I suppose I could live with putting code, archive, codebase, etc. of the 
applet into the <PARAM>s of the <OBJECT> so long as that works across 
Gecko, KHTML, Opera and IE.  It also ought to work just fine with Netscape 4.
My personal preference is that the standard format be 
classid="java:appletname", with the codebase and archive elements, etc.,
specified as attributes, but I could understand arguing against that as
forcing a Java element into an otherwise neutral markup.

Thanks very much for the pointer to the A List Apart article.

Comment 18

[Mike Cowperthwaite]

A fairly clever solution to this problem is up at:
  http://ww2.cs.fsu.edu/~steele/XHTML/appletObject.html

It's not quite as nice as a monolithic tag would be, but it looks like it would 
do the trick for all browsers.

Arun Ranganathan, do you know if there's been any advancement on the part of Sun 
in updating the registry keys under the MIME branch, such that the W3C-standard 
tag would work under IE?

Comment 19

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

I'm marking this bug as WONTFIX per bug #1269807.

For more information see - https://blog.mozilla.org/futurereleases/2015/10/08/npapi-plugins-in-firefox/