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.
Reassign to Joe as I'm leaving the role of OJI module owner.
Status: UNCONFIRMED → NEW
Target Milestone: --- → mozilla0.9.5
Ressign to Joe Chou, as I am no longer working officially on OJI.
Assignee: edburns → joe.chou
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Summary: Applet fails with Mac 9.x → WRMB: Applet fails with Mac 9.x
adding bugscape ref
Whiteboard: [bugscape: 5571]
adding Patrick due to WRMB status
topembed, WRMB, Java plugin on Mac ---->beard
Assignee: joe.chou → beard
Status: NEW → UNCONFIRMED
The site isn't loading at all for me. Is there a different URL I can try?
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....
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.
Hardware: PC → Macintosh
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.
Any changes needed to make the classic MRJ plugin work will have to be in 0.9.7.
Status: NEW → ASSIGNED
Target Milestone: mozilla0.9.6 → mozilla0.9.7
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
Assignee: beard → bnesse
Status: ASSIGNED → NEW
Target Milestone: mozilla0.9.8 → mozilla0.9.9
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...
... or I suppose it could be that alt is in invalid attribute tag for an applet element...
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.
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
oh, then perhaps the parser is getting confused since that attribute has no value?
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.
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
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.
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.)
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.
Created attachment 67475 [details] [diff] [review] 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 on attachment 67475 [details] [diff] [review] Proposed patch r=peterl
Attachment #67475 - Flags: review+
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.
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.
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.
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 firstname.lastname@example.org. You can search for "Moving bugs not scheduled for a project" to quickly delete this bugmail.
Target Milestone: mozilla1.0 → mozilla1.2
removing myself from the cc list
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.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WONTFIX
Chris Petersen is a new QA contact for oji component. His email is: email@example.com
Assignee: bnesse → petersen
fixing small error for firstname.lastname@example.org (filter with : SPAMMAILSUCKS)
Assignee: petersen → beard
QA Contact: pmac → petersen
You need to log in before you can comment on or make changes to this bug.