Closed Bug 98362 Opened 25 years ago Closed 24 years ago

No Java to Javascript when Applet started throug <object> tag

Categories

(Core Graveyard :: Java: OJI, defect)

x86
Windows 2000
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: Magnus.Kessler, Assigned: edburns)

Details

Attachments

(5 files)

From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.3) Gecko/20010801 BuildID: 2001080110 Java to Javascript communication fails when an applet is started through the <object> tag. The same applet works fine when invoked through the <embed> or <applet> tags Reproducible: Always Steps to Reproduce: 1. place the attached html und class files into a directory 2. open the file myapplet_object.html in mozilla Actual Results: after the page is loaded the applet starts, but then prints a stacktrace in the java console: netscape.javascript.JSException: JSObject.getWindow() requires mayscript attribute on this Applet at java.lang.reflect.Constructor.newInstance(Native Method) at sun.plugin.liveconnect.PrivilegedConstructObjectAction.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at sun.plugin.liveconnect.SecureInvocation.ConstructObject(Unknown Source) Note that the mayscript parameter is set. Expected Results: the applet should redirect the browser to http://www.mozilla.org. The same applet works fine with the other two html files (myapplet_applet.html, my_applet_embed.html), where the applet is invoked through the <applet> and <embed> tags. With myapplet_object.html the expected behaviour is observed in IE 5.5.
Attached file the applet itself —
Attached file the applet java code —
--> OJI component Dupe of bug 80802? "LiveConnect for HTML4 OBJECT tag currently not supported"
Assignee: rogerl → edburns
Status: UNCONFIRMED → NEW
Component: Live Connect → OJI
Ever confirmed: true
QA Contact: pschwartau → pmac
*** This bug has been marked as a duplicate of 80802 ***
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
verified dup.
Status: RESOLVED → VERIFIED
This was previously marked as a duplicate of 80802. However 80802 has been marked as fixed, and the behaviour described here can still be found in the latest nightly builds. Can someone please have another look?
Status: VERIFIED → REOPENED
Resolution: DUPLICATE → ---
This bug is already fixed by a fix for bug 109039. I propose to close it as fixed by bug fix for 109039.
Closing as FIXED according to comment #10 and my tests.
Status: REOPENED → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → FIXED
QA Contact: pmac → petersen
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: