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)
Core Graveyard
Java: OJI
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)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
hjtoi-bugzilla
:
review+
jband_mozilla
:
superreview+
|
Details | Diff | Splinter Review |
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
Target Milestone: --- → mozilla1.0
Comment 3•23 years ago
|
||
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 → ---
Comment 4•23 years ago
|
||
Reassigning to OJI component for consideration -
Assignee: rogerl → edburns
Component: Live Connect → OJI
QA Contact: pschwartau → shrir
Comment 5•23 years ago
|
||
cc'ing sean -
Comment 6•23 years ago
|
||
Comment 8•23 years ago
|
||
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.)
Comment 10•23 years ago
|
||
--- following up on #61488
Reporter | ||
Comment 11•23 years ago
|
||
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).
Comment 12•23 years ago
|
||
SPAM: reassigning all OJI bugs to new OJI QA, pmac ( 227 bugs)
QA Contact: shrir → pmac
Comment 13•23 years ago
|
||
*** Bug 98362 has been marked as a duplicate of this bug. ***
Comment 14•23 years ago
|
||
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.
Comment 15•23 years ago
|
||
Comment 16•23 years ago
|
||
cc'ing Patrick for his opinion -
Comment 17•23 years ago
|
||
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
Comment 18•23 years ago
|
||
Comment 19•23 years ago
|
||
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?
Comment 20•23 years ago
|
||
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
Comment 21•23 years ago
|
||
For the love of Mozilla, could someone please take a look at this and r= it?
Assignee | ||
Comment 22•23 years ago
|
||
Comment 23•23 years ago
|
||
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.
Assignee | ||
Comment 24•23 years ago
|
||
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 25•23 years ago
|
||
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+
Comment 26•23 years ago
|
||
Fix checked in!
Someone should really put this on the nsbranch. Seriously.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 27•23 years ago
|
||
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.
Assignee | ||
Updated•23 years ago
|
Status: NEW → ASSIGNED
Whiteboard: [HAVE FIX]
Target Milestone: --- → mozilla0.9.5
Assignee | ||
Updated•23 years ago
|
Whiteboard: [HAVE FIX] → [HAVE FIX][FIXED ON TRUNK]
Looks good, mostly moving code which makes the patch look big. nsbranch+.
Updated•23 years ago
|
Attachment #51532 -
Flags: review+
Comment 30•23 years ago
|
||
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
Comment 31•23 years ago
|
||
PDT-, let's get this in the next one.
Whiteboard: [HAVE FIX][FIXED ON TRUNK] → [HAVE FIX] [FIXED ON TRUNK] [PDT-]
Comment 32•23 years ago
|
||
0.9.5 is out the door. bumping TM up by one.
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Comment 33•23 years ago
|
||
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 ago → 23 years ago
Resolution: --- → FIXED
Comment 35•23 years ago
|
||
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
Comment 36•23 years ago
|
||
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'
Comment 37•23 years ago
|
||
please checkin to the 0.9.4 branch, and mark this bug w/ the "fixed0.9.4" once
it's on there.
Comment 39•23 years ago
|
||
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
Comment 40•23 years ago
|
||
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?
Comment 41•23 years ago
|
||
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
Comment 42•23 years ago
|
||
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/>
Comment 43•23 years ago
|
||
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 → ---
Reporter | ||
Comment 44•23 years ago
|
||
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 --
>
Comment 45•23 years ago
|
||
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
Comment 46•23 years ago
|
||
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?
Assignee | ||
Comment 47•23 years ago
|
||
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 ago → 23 years ago
Resolution: --- → FIXED
Comment 48•23 years ago
|
||
Phil. perhaps you would want to open a separate bug for the additional test case.
Restoring prior KWs.
Updated•23 years ago
|
Keywords: fixed0.9.4
Comment 49•23 years ago
|
||
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 -
Comment 50•23 years ago
|
||
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.
Comment 51•23 years ago
|
||
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
Reporter | ||
Comment 52•23 years ago
|
||
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.
Comment 53•23 years ago
|
||
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.
Comment 54•23 years ago
|
||
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
You need to log in
before you can comment on or make changes to this bug.
Description
•