341878 - Java plugins fails when the applet is in an <object> element

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Plug-ins, defect)

Description

[Jim Moe]

User-Agent:       Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.8.0.4) Gecko/20060525 SeaMonkey/1.0.2 Mnenhy/0.7.3.0
Build Identifier: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.8.0.4) Gecko/20060525 SeaMonkey/1.0.2 Mnenhy/0.7.3.0

When a Java applet is presented using an <object> tag, the Java window in the browser is disabled, the applet code is not disabled. The result is a window that is not painted, and the browser is unstable and likely to crash soon thereafter.

Here is a portion of the HTML that does not work:
<object height="300" width="500">
  classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93"
  <param name="type"     value="application/x-java-applet;">
  <param name="codebase" value="./">
  <param name="code"     value="testvm.class">
  Object tag for Java Runtime Environment is not working on your system.
</object>

Rewriting the above as an <applet> element works correctly.

Reproducible: Always

Steps to Reproduce:
1. Unzip the attached test page
2. Open file "testvm.html"

Actual Results:  
The first window is non-functional.
The second window shows the Java JVM version and animation.

Expected Results:  
Both windows should show the JVM version data.

There is some variation among users about this failure. If it fails at all, it always fails. No obvious reason for why it fails for some and not others. Reports indicate it fails on os/2 client v4.5x, server v4.5x, and eComstation 1.x.

Comment 1

[Jim Moe]

Attachment: HTML Java JVM test page

It contains the Java JVM HTML test page, and the Java applet code from Sun.

Comment 2

[Jim Moe]

See also the "Java plugin fails in SM, FF and Moz" thread in newsgroup <mozilla.dev.ports.os2>.

Comment 3

[Andrew Schultz]

==> plugins

Comment 4

[Christian :Biesinger (don't email me, ping me on IRC)]

clsid: is not supported in mozilla (unless you install the activex plugin, http://www.iol.ie/~locka/mozilla/plugin.htm)

You can use one of the ways shown in http://biesi.damowmow.com/object/032.html. Or one of the ways from http://www.student.oulu.fi/~sairwas/object-test/java/.

Comment 5

[Christian :Biesinger (don't email me, ping me on IRC)]

oh, os/2. then clsid: isn't supported at all. it's an activex thing...

Comment 6

[Jim Moe]

"Oh, os/2." Indeed. So the workarounds you noted are not applicable.

So this is neither resolved nor invalid. Whatever the case about activex, it should not tank the plugin. 

Comment 7

[Christian :Biesinger (don't email me, ping me on IRC)]

(In reply to comment #6)
> "Oh, os/2." Indeed. So the workarounds you noted are not applicable.

Eh? They are, except the ActiveX one...

> So this is neither resolved nor invalid. Whatever the case about activex, it
> should not tank the plugin. 

Oh... so this bug is about this part of comment 0?
>The result is a window
>that is not painted, and the browser is unstable and likely to crash soon
>thereafter.

Comment 8

[Jim Moe]

>Oh... so this bug is about this part of comment 0?
>>The result is a window that is not painted, and the browser 
>> is unstable and likely to crash soon thereafter.

Yes. I apologize if I was unclear about what the exact problem report is.

Based on your research, Seamonkey (and Firefox) when built for os/2, do not properly handle the "clsid:" (activex) instance, the applet is not downloaded, and the window where the applet would have run is unceremoniously abandoned.

Also the initial instance of the problem showed on <http://www.java.com/en/download/help/testvm.xml> where I have no control over the code. The provided test case is a localized version of that site.

Another note. When
  classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93"
is replaced by
  classid="testvm.class"
the plugin fails in the same way. So I suspect it is not really the "clsid:" code. That is why I reported the defect as a general problem with the <object> tag.

Comment 9

[Christian :Biesinger (don't email me, ping me on IRC)]

(In reply to comment #8)
>   classid="testvm.class"

That's still missing the java: prefix. This bug probably happens every time the clsid is unrecognized. Maybe it's even OS/2 specific.

Comment 10

[Jim Moe]

Okay. With the class ID thus:
  classid="java:testvm.class"
the plugin works as expected.

The Sun Java JVM site works okay with Firefox v1.5.0.3 in win2k.

So the problem is os/2 specific and is badly handling an unknown condition.

Comment 11

[Jim Moe]

I have just discovered another site that features this same problem. Only this one has a Flash document rather than Java. <http://www.chi-mania.co.uk/>. I expect it is the "clsid:" identifier that is the problem, as it is for the Java examples.

The offending code is:

<object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=6,0,0,0" width="511" height="276" id="flash_intro" align>
<param name="_cx" value="13520">
<param name="_cy" value="7303">
<param name="FlashVars" value>
<param name="Movie" value="flash_intro.swf">
<param name="Src" value="flash_intro.swf">
<param name="WMode" value="Transparent">
<param name="Play" value="-1">
<param name="Loop" value="0">
<param name="Quality" value="High">
<param name="SAlign" value>
<param name="Menu" value="-1">
<param name="Base" value>
<param name="AllowScriptAccess" value>
<param name="Scale" value="ShowAll">
<param name="DeviceFont" value="0">
<param name="EmbedMovie" value="0">
<param name="BGColor" value="FFFFFF">
<param name="SWRemote" value>
<param name="MovieData" value>
<param name="SeamlessTabbing" value="1">
<param name="Profile" value="0">
<param name="ProfileAddress" value>
<param name="ProfilePort" value="0"><embed src="flash_intro.swf" quality="high" wmode="transparent" bgcolor="#FFFFFF" width="511" height="276" name="flash_intro" align type="application/x-shockwave-flash" pluginspage="http://www.macromedia.com/go/getflashplayer">
</object>

Comment 12

[Peter Weilbacher]

Not sure why I never confirmed it. Still seems to be a problem on trunk, although I have no clue what we can do about it.

Comment 13

[Steve Wendt]

Is this still an issue in Gecko 2.0?  Is/was the problem only with plugins from Innotek that use Odin?

Comment 14

[Steve Wendt]

Don't think this is valid any more; reopen if there is still something broken in recent versions.