100841 - WRMB: Applet fails with Mac 9.x

Status: RESOLVED WONTFIX

(Core Graveyard :: Java: OJI, defect)

Description

[/\/\arcio Galli]

I am investigating one case and wondering if you heard about this. This applet
in this page is displaing: 
Java-Lang.Array Index Out Of Bounds Exception 0 >=0 
 
And this (menu applet) do not properly work. This happens with Mac 9.x.

Comment 1

[edburns]

Reassign to Joe as I'm leaving the role of OJI module owner.

Comment 2

[edburns]

Ressign to Joe Chou, as I am no longer working officially on OJI.

Comment 3

[rubydoo123]

adding bugscape ref

Comment 4

[rubydoo123]

adding Patrick due to WRMB status

Comment 5

[Peter Lubczynski]

topembed, WRMB, Java plugin on Mac ---->beard

Comment 6

[Patrick C. Beard]

The site isn't loading at all for me. Is there a different URL I can try?

Comment 7

[Peter Lubczynski]

Strange, only works if there is a slash at the end:

http://www.ed.gov/DirectLoan/

Applet loads fine in Windows, can't test on Mac at the moment....

Comment 8

[Peter Lubczynski]

Wait a sec...not that this bug isn't important, but why is this topembed and
WRMB if it only happens on Mac? Confirming error on a trunk build with OS 9.2.

Comment 9

[Patrick C. Beard]

Applet runs correctly on Mac OS X with new MRJ Carbon plugin... Perhaps the
applet has JDK 1.2 dependencies? If so, it will never work in Mac OS 9.

Comment 10

[Marek Z. Jeziorek]

removing topembed

Comment 11

[Patrick C. Beard]

Any changes needed to make the classic MRJ plugin work will have to be in 0.9.7.

Comment 12

[Olaf Christoffel]

oh my goodness, i forgot to report this.

it's may be the solution to this bug.

I was testing the mac java plugin with mozilla and had always this 
Java-Lang.Array Index Out Of Bounds Exception 0 >=0.

With netscape 4.x it was running, but in mozilla not, so I thought that this
could not be the applet. 

So I played around with the applet tag, and then at one time, the
Java-Lang.Array Index Out Of Bounds Exception 0 >=0 error was away.


This was the applet tag before (with the error):

<APPLET  NAME="JTreeViewApplet" ARCHIVE="JAVATreeR.jar" code="FCOTreeR.class" 
codebase="../../../_java/client/navigation/" MAYSCRIPT WIDTH=210 HEIGHT=800>

and this the one which worked:

<APPLET  NAME="JTreeViewApplet" ARCHIVE="JAVATreeR.jar" code="FCOTreeR.class" 
codebase="../../../_java/client/navigation/" WIDTH=210 HEIGHT=800 MAYSCRIPT>

I think that if the width and height attribute is behinde the MAYSCRIPT tag it
will result in the array error, if those attributes are before the MAYSCRIPT tag
it will work. It may be not the MASCRIPT tag which cause the error, but if width
and height is in the wrong place, it will probably result in the array error.

may this helps to you.

greetz olaf

Comment 13

[Patrick C. Beard]

-> bnesse

Comment 14

[Brian Nesse (gone)]

The problem here is that the applet declaration reads:
<applet code="slidem.class" align="top" alt="" width="240" height="450">

The alt="" is what's killing it. It would seem tags with no values are the issue
here...

Comment 15

[Brian Nesse (gone)]

... or I suppose it could be that alt is in invalid attribute tag for an applet
element...

Comment 16

[rubydoo123]

The attribute value ALT is valid for the APPLET element, and the attribute value 
can be empty. MAYSCRIPT is not a valid attribute, however, since it is invalid 
it should be ignored. Placement order of the attributes is not an issue, or at 
least should not be, that is not a requirement within the 4.x spec.

Comment 17

[Peter Lubczynski]

A test for an applet tag may need to be added to
|nsPluginInstanceOwner::GetMayScript| to get MAYSCRIPT from the PARAM tags
instead of attributes:

http://lxr.mozilla.org/mozilla/source/layout/html/base/src/nsObjectFrame.cpp#2852

Comment 18

[Patrick C. Beard]

Um, MAYSCRIPT is indeed a valid attribute for applets. It's used to 
indicate that the applet may be using netscape.javascript.JSObject to call 
back into the page's JavaScript code.

It may not be part of the W3C specification for the tag, but we have always 
supported it.

Comment 19

[Peter Lubczynski]

oh, then perhaps the parser is getting confused since that attribute has no value?

Comment 20

[Patrick C. Beard]

It's supposed to be legal to have an attribute with an empty value. Try it with
MAYSCRIPT="TRUE" for absolute clarity. If that fixes it, then perhaps it's a bug
in the parser. I believe that 4.X supported this.

Comment 21

[rubydoo123]

Hey Patrick: you are right, it is not a valid APPLET attribute according to the 
W3C spec, so I guess it is a Netscape extentsion

Comment 22

[Brian Nesse (gone)]

Yes, I was entirely incorrect, as I discovered shortly after my second post... 
alt is quite valid for applets, it's just documented somewhere else. The empty 
value is what you are supposed to pass in rather than a "garbage" string if you 
don't have any useful alternate text.

I believe that the parser is somehow choking on the empty string. In my initial 
test, I simply replaced the 'alt=""' with whitespace and it came right up. I 
stepped through it quickly a second time and it seemed like all of the attributes 
(JVMTagInfo<something>... I don't remember the object off the top of my head) 
were empty. I'll look more carefully tomorrow.

Comment 23

[Brian Nesse (gone)]

This appears to be a bug in the Apple MRJ implementation. Whether I run the
applet in 4.x, 6.x, or through Apple's Applet Viewer I see the same warnings
thrown from MRJ:
 Warning: <applet> tag requres width attribute. (changes to whatever attribute
 is immediately after the alt="" attribute if you move it)

This is followed by a bunch of additional warnings that read:
 Warning: <param> tag outside <applet> ... </applet>

What I'm still not clear on is why the applet subsequently runs under 4.x but
fails under 6.x... maybe we are doing a better job of checking for errors in 6.x
or something.

One possible workaround for this would be to insert a space in any empty
attributes (or possibly just for the alt attribute... I'll have to check if ""
is valid for any of the others.)

Comment 24

[Brian Nesse (gone)]

Arrrgh! I finally figured out that this is only working for me in 4.x because
the "use java plugin" checkbox had been disabled... it was using the built-in
JRE. When I re-enable the MRJ plug-in it stops working in 4.x as well.

Comment 25

[Brian Nesse (gone)]

Attachment: Proposed patch

The attached patch works around the Apple MRE bug by scanning the applet tag
for an empty parameter ("" does not appear to be valid for any other attribute)
and inserts a space character in it.

reviews please.

Comment 26

[Peter Lubczynski]

Comment on attachment 67475 [details] [diff] [review]
Proposed patch

r=peterl

Comment 27

[Peter Lubczynski]

Comment on attachment 67475 [details] [diff] [review]
Proposed patch

r=peterl

Comment 28

[Patrick C. Beard]

Comment on attachment 67475 [details] [diff] [review]
Proposed patch

This kind of  fix worries me, as it means that there's no way to pass an empty
string as an attribute, which should be perfectly legitimate. Let's consider
discussing this with Apple and see if there's a better way.

Comment 29

[Brian Nesse (gone)]

True, but as far as I can tell, the only attribute that "" is valid for is the
alt attribute. It wouldn't make any sense for height, width, code, codebase,
etc. Not that we shouldn't talk to Apple about it, but I believe it's a safe
workaround.

Comment 30

[rubydoo123]

Actually, I believe most of the attributes can have a value of "". Looking at 
the 4.01 Transitional DTD, any attribute that has a declared value of CDATA, can 
be empty. In the case of the APPLET element, that is basically every attribute 
(align has a preset set of values). Any Netscape extension such as MAYSCRIPT, 
would need to be reviewed for allowable content.

Comment 31

[scottputterman]

Moving Netscape owned 0.9.9 and 1.0 bugs that don't have an nsbeta1, nsbeta1+,
topembed, topembed+, Mozilla0.9.9+ or Mozilla1.0+ keyword.  Please send any
questions or feedback about this to [e-mail].  You can search for
"Moving bugs not scheduled for a project" to quickly delete this bugmail.

Comment 32

[rubydoo123]

removing myself from the cc list

Comment 33

[Brian Nesse (gone)]

This is a bug in the Apple MRJ. The only work around has been deemed unsafe.
Apple has end of lifed OS9. This isn't getting fixed. WONTFIX.

Comment 34

[Patty Mac]

Chris Petersen is a new QA contact for oji component. His email is:
[e-mail]

Comment 35

[Matthias Versen [:Matti]]

fixing small error for [e-mail] (filter with : SPAMMAILSUCKS)