Closed Bug 80802 Opened 23 years ago Closed 23 years ago

LiveConnect for HTML4 OBJECT tag currently not supported

Categories

(Core Graveyard :: Java: OJI, defect, P2)

Tracking

(Not tracked)

VERIFIED FIXED
mozilla0.9.6

People

(Reporter: bcortez, Assigned: jst)

References

()

Details

(Keywords: crash, qawanted, Whiteboard: [HAVE FIX] [FIXED ON TRUNK] [PDT-])

Attachments

(3 files)

This bug has been submitted as a new feature request as a result of bug 75588. LiveConnect requires the use of the APPLET tag to work without throwing a JAVA exception. However, both the APPLET and EMBED tags have been deprecated in the W3C HTML4 specification in favor of the OBJECT tag. If the OBJECT tag is not supported in Mozilla, then (sadly) Mozilla CANNOT claim full HTML4 compliance for it's browser. This is a request to add support for the OBJECT tag in Mozilla.
Added the testcase URL
Keywords: crash, qawanted
Target Milestone: --- → mozilla1.0
To Harish
Assignee: clayton → harishd
Object is supported. What is not supported is LiveConnect for Object. Reassigning accordingly. Clearing milestone -- that's for the assignee to set.
Assignee: harishd → rogerl
Status: UNCONFIRMED → NEW
Component: HTML Element → Live Connect
Ever confirmed: true
QA Contact: bsharma → pschwartau
Summary: HTML4 OBJECT tag currently not supported → LiveConnect for HTML4 OBJECT tag currently not supported
Target Milestone: mozilla1.0 → ---
Reassigning to OJI component for consideration -
Assignee: rogerl → edburns
Component: Live Connect → OJI
QA Contact: pschwartau → shrir
cc'ing sean -
Note related bug 1776 and bug 46569. XPConnect of XPCOM plugins instantiated via the object tag was working the last time I checked, so as Boris noted, this must specifically be a LiveConnect problem.
Joe, can you please look at this bug
Assignee: edburns → joe.chou
Priority: -- → P4
FYI, we had no problem getting this working on an Moz 0.6 codebase. We did it for our OS/2 release. See my attachment in: http://bugzilla.mozilla.org/show_bug.cgi?id=61488 It looks like when jst changed the architecture of the mInner on Dec 23, this got much harder (see the cvs logs for nsHTMLAppletElement, nsHTMLEmbedElement, etc.)
*** Bug 61488 has been marked as a duplicate of this bug. ***
--- following up on #61488
Status: NEW → ASSIGNED
Has anyone looked into testing the code attachment from bug 61488 (From Michael Kaply 2001-06-15 12:50, attachment id=38645)? It seems as if this may be the solution, since it works for him in OS/2 (and looks platform independent).
SPAM: reassigning all OJI bugs to new OJI QA, pmac ( 227 bugs)
QA Contact: shrir → pmac
*** Bug 98362 has been marked as a duplicate of this bug. ***
More info on this: The issue is in http://lxr.mozilla.org/seamonkey/source/dom/src/base/nsDOMClassInfo.cpp#4142 This line: nsCOMPtr<nsIScriptablePlugin> spi(do_QueryInterface(plugin_inst)); is failing in the Object/Embed case. The only thing I see in plugins that adds support for nsiscriptableplugin is: http://lxr.mozilla.org/seamonkey/source/modules/plugin/base/src/ns4xPluginInstan ce.cpp#629 NS_IMPL_ISUPPORTS2(ns4xPluginInstance, nsIPluginInstance, nsIScriptablePlugin) Any help is appreciated.
cc'ing Patrick for his opinion -
This is not an enhancement. This is a major problem. If the OBJECT tag is to replace APPLET and you can't do LiveConnect on it, it's a big problem. I'm taking ownership of this since I am near a fix. I know my fix isn't the "right" thing. I will rework it to check for an nsIScriptablePlugin first and if there is none, check the JVM.
Assignee: joe.chou → mkaply
Severity: enhancement → major
Status: ASSIGNED → NEW
Priority: P4 → P2
Thanks, Mike, for providing a patch. Curruntly, I am working on some more urgent issues (top crash bug, etc.). This is the patch similar to your OS2 patch for supporting OBJECT tag in liveconnect earlier, right?
This patch was actually much easier to do on the new code.l It is a VERY small patch. Essentially there was no JVM code in the Object/Embed path. All I did was duplicate the code from APPLET for getting the JVM in the case that we were asked for a JSObject, but the plugin isn't scriptable. This is a VERY safe fix, and makes EMBED and OBJECT work great with LiveConnect. we need this.
Status: NEW → ASSIGNED
For the love of Mozilla, could someone please take a look at this and r= it?
Wow, CVS sure made that patch unclear as to what it was doing :) Patch looks good to me and still works. I probably can't r= because it is DOM, but r=mkaply.
Mkaply, your r= is very much appreciated :-) Jband, wanna sr= this one? The change is to make nsHTMLPluginObjElementSH inherit nsHTMLAppletElementSH, and nsHTMLPluginObjElementSH::GetPluginJSObject() now calls into the inherited GetPluginJSObject()... The change is really a 5 line change (modulo moving code around), but cvs makes the patch look big and complicated, as mkaply already noticed :-)
Comment on attachment 51532 [details] [diff] [review] Same as above, only less code (reuse the existing applet related code) sr=jband
Attachment #51532 - Flags: superreview+
Fix checked in! Someone should really put this on the nsbranch. Seriously.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
This one I'd be happy to put on the branch assuming that is still possible, nominating. The patch hardly changes anything, no new code, just moves things around and changes the class hierarchy for our plugin/applet scriptable helpers and makes one call into the other in case we're wrapping a plugin that's not scriptable in the normal sense to make Java *plugins* work. Significant gain for wery low cost. Reopening to try to get this one the branch.
Status: RESOLVED → REOPENED
Keywords: nsbranch
Resolution: FIXED → ---
Taking bug.
Assignee: mkaply → jst
Status: REOPENED → NEW
Status: NEW → ASSIGNED
Whiteboard: [HAVE FIX]
Target Milestone: --- → mozilla0.9.5
Whiteboard: [HAVE FIX] → [HAVE FIX][FIXED ON TRUNK]
Looks good, mostly moving code which makes the patch look big. nsbranch+.
Keywords: nsbranchnsbranch+
Comment on attachment 51532 [details] [diff] [review] Same as above, only less code (reuse the existing applet related code) Patch looks fine to me for the branch. r=av
PDT-, let's get this in the next one.
Whiteboard: [HAVE FIX][FIXED ON TRUNK] → [HAVE FIX] [FIXED ON TRUNK] [PDT-]
0.9.5 is out the door. bumping TM up by one.
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Since this is on the trunk and was marked PDT-, it's already made it into 0.9.6. Marking fixed.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → FIXED
Verified the patch
Status: RESOLVED → VERIFIED
Looks like this just missed the branch, but now I think the mozilla 0.9.4 branch may also really want this fix. Nominating edt0.9.4
Keywords: edt0.9.4
Keywords: vtrunk
Here is the testcase from the duped bug #61488 http://www.hubick.com/software/Misc/LiveConnect/test5.htm Fix is verified on trunk but LiveConnect is not working with OBJECT element on the 0.9.4ec branch. As Johnny quoted on 10/10: 'Significant gain for very low cost'
please checkin to the 0.9.4 branch, and mark this bug w/ the "fixed0.9.4" once it's on there.
Keywords: edt0.9.4edt0.9.4+
Fixed on the mozilla0.9.4 branch.
Keywords: fixed0.9.4
I verified on windows 98 (commerical trunk: 2002-01-16-06-trunk) and the applets load fine. However, on the branch build:(2001-01-16-22-094EC), run this url comment#36: http://www.hubick.com/software/Misc/LiveConnect/test5.htm it loads fine, but the first url that the orginal reporter reported in this bug, the applets not load, missing the two buttons (the texts of two buttons should be: "call Javascript function to refresh the time/date" &" call javascript alert box directly". Phil, could you verify please? This is liveconnect bug.
QA Contact: pmac → pschwartau
Phil, I meant if clicking on this url--the reporter reported in this bug. http://www.ccs.neu.edu/home/bcortez/mozilla_tests/80802/bug_test.html the applet buttons are missing. However, the url from comment #36 is loading fine (jre 1.3.1, branch build: (2001-01-16-22-094EC) Here is the url: http://www.hubick.com/software/Misc/LiveConnect/test5.htm Can you verify this please?
Confirming what Patty has reported: The testcase http://www.hubick.com/software/Misc/LiveConnect/test5.htm is working fine in both my trunk and branch build on WinNT However, the original testcase for this bug, http://www.ccs.neu.edu/home/bcortez/mozilla_tests/80802/bug_test.html, does not work in my Netscape branch build 2002011622_0.9.4ec on WinNT. It does, however, function correctly in my Mozilla trunk build 2002011604: WHEN IT WORKS (on trunk) The applet loads and contains two buttons: "Call JavaScript function to refresh time and date" "Call JavaScript alert box directly" Both of these function correctly. This is the output in the Java Console: JSObjectTestApplet: Entering init() JSObjectTestApplet: JSObject is [object Window] WHEN IT DOESN'T WORK (on the branch) The applet doesn't display either of the buttons. And in the Java Console: JSObjectTestApplet: Entering init() 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) Here is the HTML for the applet involved: <object classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93" width="100%" height="20%" align="baseline" codebase="http://java.sun.com/j2se/1.3/jre/download-windows.html"> <param NAME="code" VALUE="JSObjectTestApplet.class"> <param NAME="codebase" VALUE="lib"> <param NAME="scriptable" VALUE="true"> <param NAME="mayscript" VALUE="true"> <param NAME="type" VALUE="application/x-java-applet;version=1.3"> <embed type="application/x-java-applet;version=1.3" width="100" height="100" align="center" java_CODE=JSObjectTestApplet.class mayscript="true" pluginspage="http://java.sun.com/j2se/1.3/jre/download-windows.html"> <noembed> </COMMENT> No JDK 1.2 support for APPLET!! </noembed> </embed> </object> Note the <param NAME="mayscript" VALUE="true"> !!!
QA Contact: pschwartau → pmac
Here is the HTML for the applet in the other testcase, the one that works on both trunk and branch: <object name="TestApplet" id="TestApplet" classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93" width="300" height="100" codebase="j2re1_3_0-win.exe#Version=1,3,0,0" mayscript="true" scriptable="true"> <param name="type" value="application/x-java-applet;version=1.3"/> <param name="mayscript" value="true"/> <param name="scriptable" value="true"/> <param name="code" value="Test5Applet"/> </object><br/>
Based on what Patty and I have found, reopening this bug. Again, the problem seems to be only on the branch -
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
It seems that the OBJECT tag has been coded to look for the "mayscript" (and perhaps also "scriptable") setting as part of the object tag attribute list. However, according to section 13.3 of the W3C HTML 4.01 Specification (see: http://www.w3.org/TR/html401/struct/objects.html#h-13.3 ) "mayscript" is not a valid attribute. Therefore, it must be placed in the code as a PARAM, right?? Since "To specify run-time values, however, authors use the PARAM element". (Relevant snippet from W3C spec below) 13.3 Generic inclusion: the OBJECT element <!ELEMENT OBJECT - - (PARAM | %flow;)* -- generic embedded object --> <!ATTLIST OBJECT %attrs; -- %coreattrs, %i18n, %events -- declare (declare) #IMPLIED -- declare but don't instantiate flag -- classid %URI; #IMPLIED -- identifies an implementation -- codebase %URI; #IMPLIED -- base URI for classid, data, archive-- data %URI; #IMPLIED -- reference to object's data -- type %ContentType; #IMPLIED -- content type for data -- codetype %ContentType; #IMPLIED -- content type for code -- archive CDATA #IMPLIED -- space-separated list of URIs -- standby %Text; #IMPLIED -- message to show while loading -- height %Length; #IMPLIED -- override height -- width %Length; #IMPLIED -- override width -- usemap %URI; #IMPLIED -- use client-side image map -- name CDATA #IMPLIED -- submit as part of form -- tabindex NUMBER #IMPLIED -- position in tabbing order -- >
In the case of an OBJECT tag, we should be checking the parameters instead of the attriubtes for "MAYSCRIPT". See: http://lxr.mozilla.org/mozilla/source/layout/html/base/src/nsObjectFrame.cpp#2771
This was set to edt094 in Novemember. This was considered fixed on the 094 branch, but has been reopened. Is the remaininng change necessary for 094? Or should we minus?
I don't see any proof of this not working on the 094 branch, I do see problems with the applet on the URL in this bug, but we never even get far enough to call through LiveConnect or anything like that. The applet doesn't load correctly, mozilla says the applet is loading, but the applet never draws the buttons that it's supposed to draw. Closing this bug again, since the code that deals with LiveConnect when applets are used in OBJECT tags is on the branch and AFAICT it's working. Peter, if the problem about the applet not loading correctly on the branch needs to be fixed on the branch then please open a new bug on that problem and nominate appropriately.
Status: REOPENED → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → FIXED
Phil. perhaps you would want to open a separate bug for the additional test case. Restoring prior KWs.
I have filed bug 121529 on this against OJI: "Test applet doesn't load in branch builds" I wasn't sure what keywords were appropriate for the new bug; someone may like to add them. I have cc'ed most people from this bug; apologies if I left anyone out who would like to follow the new bug -
Yes, I confirm that this testcase works on the trunk but not the 0.9.4 branch: http://www.ccs.neu.edu/home/bcortez/mozilla_tests/80802/bug_test.html The reason for this is because the MAYSCRIPT flag isn't getting set correctly by layout when Java asks. This was fixed on the trunk in bug 109039. I'm nominating that bug for the 0.9.4 branch.
The testcase http://www.hubick.com/software/Misc/LiveConnect/test5.htm is working fine in both trunk and 0.9.4 branch on my windows 98. Therefore, this bug is fixed. Verified. The original test case that works on the trunk build (2002-01-23-06-trunk) but not the 0.9.4 branch. http://www.ccs.neu.edu/home/bcortez/mozilla_tests/80802/bug_test.html Please refers to bug 109039.
Status: RESOLVED → VERIFIED
How can you mark this as fixed when the original URL testcase still doesn't work!! Just because a single testcase (and additional testcase at that) works, doesn't mean that it is truly fixed! This was filed as a result of the original bug 75588 concerning the JSObject error about the missing MAYSCRIPT parameter. That is STILL the same failure, and it's considered FIXED because a completely different testcase (that has an incorrect usage of the OBJECT tag) passes?!?!?! This is unbelievable.
bcortez@kronos.com: you are right, there has been some confusion and the original issue concerning MAYSCRIPT in bug 75588 was lost here. The bug for this issue is bug 109039, "Mayscript attribute needed on <OBJECT> tag; this is not HTML4 compliant". I have cc'd you there and included the link to the original URL testcase. This problem has been solved on the trunk, but not on the branch.
Reporter: The URL in the testcase is FIXED and VERIFIED on the trunk so it is the correct procedure to close out this bug. However, if it's not fixed on the trunk, feel free to re-open. The 0.9.4 branch has a different procedure and check-ins need to be approved after they have been FIXED on the trunk. In order for this to be fixed on the 0.9.4 branch, the patch from bug 109039 is needed. Add comments to that bug to get approved.
Keywords: fixed0.9.4
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: