192430 - Java <OBJECT>s not included in document.applets[]

Status: RESOLVED WONTFIX

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

Description

[Mike Cowperthwaite]

User-Agent:       Opera/7.01 (Windows NT 5.0; U)  [en]
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130

If an applet is instantiated using <OBJECT classid="java:appletname"...>, the 
object is created just fine but it is not included in the document.applets[] 
array.




Similarly, when instantiating an applet using either


 <OBJECT type="application/java"...><PARAM name="code" value="appletname">


or


 <OBJECT type="application/java" code="appletname"...>


However, these tags perform a direct invocation of the Java plug-in, and so 
perhaps should be included in document.embeds[] instead.  (They appear in 
neither.)




These objects *are* addressable by their 'name' or 'id' attributes, if so 
equipped. (e.g.  <OBJECT name='a' ...>  ==>  document.a)  As a workaround, this 
technique is not so useful because other browsers (e.g. Opera7) don't 
necessarily make them accessible via name or id.




For reference: Netscape 4 placed the 'classid' form in applets[]; until 4.78, 
the other two went into embeds[], but from 4.78 on, into applets[].  IE/Win and 
Opera both place all forms of these objects into applets[].


Reproducible: Always

Steps to Reproduce:
1.


2.


3.

Comment 1

[Mike Cowperthwaite]

Attachment: Code exhibiting problem

To see an example of the problem, load this attachment HTML file on a Mozilla
with a usable Java.  It contains six different tag formats for invoking
applets. When the applets are done loading, click the 'Sniff' link; the script
will simply load the two input fields with the number of items in applets[] and
embeds[], respectively.
These two numbers should add up to the number of displayed applets (five, on my
system).

Comment 2

[Boris Zbarsky [:bzbarsky]]

To plugins; the DOM currently has no good way to tell when an <object> is a Java
plugin, do we?

Comment 3

[Peter Lubczynski]

cc:ing arun and jst
This is very similar to bug 184722: Flash FSCommands are failing because it
expects OBJECTS to be in the document.embeds[] array. I recall positioning was
important because some scripts expect a certain index. I've attached the patch I
was working on to that bug.

This bug can be solved in much the same way. If a running plugin is Java, you
should be able to QI the nsIPluginInstance to nsIJVMPluginInstance.

Comment 4

[John Rutherford]

We currently use this mechenism a great deal in our Enterprise applications.
Using something like this as a workaround works fine for now:
if(is_nav5_up){
      hApplet = eval( "window.top.opener.document.getElementById('" + strParam +
"Applet')");
    }
    else{
      hApplet = eval( "window.top.opener.document.applets['" + strParam +
"Applet']");
    }

But it sure would be nice to have this work without having to kludge a switch.
Thanks,  My 2 cents worth

Comment 5

[Mike Cowperthwaite]

Wow, I think this is the first bug I ever filed -- it just saw its first activity in six-and-a-half years when Phil updated the QA contact.  Heh.

The described behavior still manifests in Fx 3.5.2, but the test page I posted is broken because I'm no longer hosting that applet.  I have a slightly modified version of the HTML file which loads the applet from disk.  If anyone ever looks at this (ha, as if) and wants to fix it, let me know and I'll provide the applet & modified HTML -- or just write your own, practically any applet will do.  I only have a .class file now, I lost the source somewhere along the way; but all the applet does is display the version of Java as text in a panel -- dumb as dirt.

IE (8) and Opera (9.64) still include all of the (successful) rendered forms in the applets[] array; IE fails on two of the forms, Opera renders all six correctly.  Firefox fails to render only the ActiveX-style invocation, as expected.

Comment 6

[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/