Closed
Bug 108557
Opened 23 years ago
Closed 22 years ago
Remove JAVA_CLASS_ID support for OBJECT tag
Categories
(Core Graveyard :: Java: OJI, defect, P3)
Core Graveyard
Java: OJI
Tracking
(Not tracked)
RESOLVED
FIXED
mozilla1.0
People
(Reporter: xiaobin.lu, Assigned: peterl-bugs)
References
()
Details
Attachments
(2 files, 6 obsolete files)
2.49 KB,
patch
|
peterlubczynski-bugs
:
review+
beard
:
superreview+
asa
:
approval+
|
Details | Diff | Splinter Review |
397 bytes,
text/html
|
Details |
From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt) BuildID: 20011016(Mozilla 0.9.5+) Essentially the implementation of object tag support is wrong. See the code below(nsObjectFrame.cpp ln 938) 938 if (classid.Find("clsid:") != -1) { 939 classid.Cut(0, 6); // Strip off the "clsid:". What's left is the class ID. 940 bJavaPluginClsid = (classid.EqualsWithConversion(JAVA_CLASS_ID)); 941 } 942 943 // if we find "java:" in the class id, or we match the Java 944 // classid number, we have a java applet 945 if(bJavaObject || bJavaPluginClsid) { 946 if (NS_FAILED(rv = GetBaseURL(*getter_AddRefs(baseURL)))) return rv; 947 948 nsAutoString codeBase; So basically JAVA_CLASS_ID has a fixed value, how about if the future JAVA_CLASS_ID would be changed. Such as if the user uses a more recent class id, Mozilla will not show the applet well. So I suggest that the code should not have any assumption about the class id, just leave this to Java plugin implementation itself. Reproducible: Always Steps to Reproduce: 1. Install JRE 1.4 to your systems and use regxpcom to register the plugins. 2. Go to http://www.coastnew.com/test1/test1-1.htm 3. Actual Results: The applet should be shown. Expected Results: The applet can not be shown.
Reporter | ||
Comment 1•23 years ago
|
||
Add stanley to cc list
Comment 2•23 years ago
|
||
*** Bug 108555 has been marked as a duplicate of this bug. ***
Comment 3•23 years ago
|
||
And while we're in here, could we change this code not to use things like Cut() if they can be avoided? :)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 4•23 years ago
|
||
Handing off to plugins, where I think this code was created.
Assignee: attinasi → av
Component: Layout → Plug-ins
QA Contact: petersen → shrir
Updated•23 years ago
|
Summary: The implementation of Object support in Mozilla is wrong → classid for Java plugin should not be hard-coded in object frame
--> OJI
Assignee: av → joe.chou
Component: Plug-ins → OJI
QA Contact: shrir → pmac
Reporter | ||
Comment 6•23 years ago
|
||
I changed the summary of this bug as: Mozilla should ignore Object tag completely. The current Mozilla object tag support assumes a fixed Java class id, however, it is going to be change anyway. Also, use the new class id will not have the correct behavior. So I think Mozilla should ignore the object tag completely.
Summary: classid for Java plugin should not be hard-coded in object frame → Mozilla should ignore object tag
Reporter | ||
Comment 7•23 years ago
|
||
Reporter | ||
Comment 8•23 years ago
|
||
Joe or Patrick: Would you guys mind reviewing the patch for me? Thanks in advance!
Comment 9•23 years ago
|
||
Comment on attachment 57495 [details] [diff] [review] The patch for ignoring the object tag with clsid attribute r=peterl I guess classid is only for ActiveX
Attachment #57495 -
Flags: review+
Updated•23 years ago
|
OS: Windows NT → All
Hardware: PC → All
Reporter | ||
Comment 10•23 years ago
|
||
Peter: Thank you for reviewing. I think we may need to take off the clssid="java:classname" support too. The problem is the codebase with object tag is interpreted by w3c as the plugin cab file URL. However, the java plugin think it is a URL where to get the class file. Also to keep consistent, if we remove classid="classid number", there is no reason to leave classid="java.classname" support here. New patch will come soon...
Reporter | ||
Comment 11•23 years ago
|
||
Reporter | ||
Comment 12•23 years ago
|
||
Peter or Joe: Can either of you review the patch? Thank you very much! Xiaobin
Comment 13•23 years ago
|
||
Comment on attachment 58294 [details] [diff] [review] Removed both clsid="THE CLASS ID" and clsid="java:className" support r=peterl, do you know what the clsid="java:className" support was used for?
Attachment #58294 -
Flags: review+
Reporter | ||
Comment 14•23 years ago
|
||
clsid=java.classname is used for displaying applet. This is another form of object tag with clsid used around a lot.
Comment 15•23 years ago
|
||
The last patch is needed for bug 111648. Patrick, can you sr=?
Blocks: 111648
Comment 16•23 years ago
|
||
Comment on attachment 58294 [details] [diff] [review] Removed both clsid="THE CLASS ID" and clsid="java:className" support sr=beard
Attachment #58294 -
Flags: superreview+
Comment 17•23 years ago
|
||
What is teh status of this one? Patch hash both r/sr. May be it is the time for someone to check it in?
Comment 18•23 years ago
|
||
The patch does not apply to a tree. For one thing, the actual patch file is corrupted (some lines got wrapped in it). Please attach a patch that can actually be checked in....
Reporter | ||
Comment 20•23 years ago
|
||
Comment 21•23 years ago
|
||
The updated patch still has lines hard-wrapped at 80 chars. Try applying it to a tree.... it fails.
Reporter | ||
Comment 22•23 years ago
|
||
Boris: Can you elaborate what hard-wrapper is?
Comment 23•23 years ago
|
||
From the patch: - classid.Cut(0, 6); // Strip off the "clsid:". What's left is the class ID. The linebreak between "class" and "ID" is present in the patch. That means that the patch cannot possibly apply to a tree -- a patch that would apply would have something like: - classid.Cut(0, 6); // Strip off the "clsid:". What's left is the class ID. The reason I bring this up is because I spent about 30 minutes editing the patch by hand in attempts to make it apply so that I could check it in. In the end it was still not applying and I was loath to make further edits without better understanding of the code.
Comment 24•23 years ago
|
||
I have updated Xiaobin's patch to seamlessly apply to the tree (without any semantic changes). Probably now it can finally go in ...
Attachment #57495 -
Attachment is obsolete: true
Attachment #58294 -
Attachment is obsolete: true
Attachment #70641 -
Attachment is obsolete: true
Comment 25•23 years ago
|
||
Sure if reviewers are happy with it... I don't know this code, but the new patch looks nothing like the old one to me...
Reporter | ||
Comment 26•23 years ago
|
||
Looks good to me. r= Xiaobin
Comment 27•23 years ago
|
||
Oh, and get driver approval (drivers@mozilla.org), please (needed for checkin before 1.0).
Reporter | ||
Comment 28•23 years ago
|
||
Igor: Would you please check that patch in for me? Thanks! Xiaobin
Comment 29•23 years ago
|
||
Xiaobin: sorry, i have no permissions to check code in myself. May be Peter Lubczynski can help with this.
Comment 30•23 years ago
|
||
-->taking bug In the new patch, the JAVA_CLASS_ID definition was forgoten to be removed. I'll fix that and check it in as soon as I get drivers approval.
Comment 31•23 years ago
|
||
Comment on attachment 70902 [details] [diff] [review] Updated patch without wrapped lines (from comments)
Attachment #70902 -
Flags: superreview+
Attachment #70902 -
Flags: review+
Comment 32•23 years ago
|
||
-->back to Xiaobin to explain this bug to drivers
Assignee: peterl → xiaobin.lu
Updated•23 years ago
|
Attachment #70902 -
Flags: superreview+
Reporter | ||
Comment 33•23 years ago
|
||
Peter, I reassinged this bug to you because I am not officially work for browser team and I am afraid that I will miss your schedule. If you can take this bug, it will be nice. I have sent email to Mozilla drivers and Mike to explain the detail of the bug. I hope that can also help you. Also since you have another bug blocked by this, it makes sense for you to own it.
Comment 34•23 years ago
|
||
Comment on attachment 70902 [details] [diff] [review] Updated patch without wrapped lines > PRBool bJavaObject = PR_FALSE; <snipped removed code> > >+ if (bJavaObject) { This has no sense for me, because this if statement never executed. Either it should be removed completely, or bJavaObject should be set to PR_TRUE sometimes ;-)
Attachment #70902 -
Flags: needs-work+
Comment 35•23 years ago
|
||
Let's try this again. Here's another patch to ONLY remove JAVA_CLASS_ID and use some better string ussage from bug 64209. Please review.
Attachment #70902 -
Attachment is obsolete: true
Comment 36•23 years ago
|
||
-->back to me
Comment 37•23 years ago
|
||
This time looks good :-) One question though: do we need 'classid.Cut()'? It seems that it's not used anymore (MakeAbsoluteURL is removed), so bJavaObject = (Substring(classid, 0, 5) == NS_LITERAL_STRING("java:")); will suffice.
Comment 38•23 years ago
|
||
Marking nsbeta1+ per ADT triage. This bug addresses part of the problem in bug 111648.
Keywords: nsbeta1+
Comment 39•22 years ago
|
||
We don't need it anymore, I believe.
Comment 40•22 years ago
|
||
Comment on attachment 72025 [details] [diff] [review] get rid of classid.Cut() r=peterl
Attachment #72025 -
Flags: review+
Comment 41•22 years ago
|
||
Comment on attachment 72025 [details] [diff] [review] get rid of classid.Cut() Why not simply use nsCRT::strncmp() to do the comparisons, rather than Substring()? http://lxr.mozilla.org/seamonkey/source/xpcom/ds/nsCRT.h#208
Attachment #72025 -
Flags: needs-work+
Comment 42•22 years ago
|
||
This is exactly the same question I asked in related bug #64209: what's more effective: nsCRT::strncmp or Substring() and compare? I guess former.
Comment 43•22 years ago
|
||
to get sr= :-)
Updated•22 years ago
|
Target Milestone: mozilla0.9.9 → mozilla1.0
Comment 44•22 years ago
|
||
Can we get r=/sr= here again? BTW, this bug also prevents better fix for bug #130605 :-)
Comment 45•22 years ago
|
||
Comment on attachment 72967 [details] [diff] [review] using nsCRT::strncmp this time r=peterl
Attachment #72967 -
Flags: review+
Comment 46•22 years ago
|
||
Comment on attachment 72967 [details] [diff] [review] using nsCRT::strncmp this time sr=beard
Attachment #72967 -
Flags: superreview+
Comment 47•22 years ago
|
||
Comment on attachment 72967 [details] [diff] [review] using nsCRT::strncmp this time a=asa (on behalf of drivers) for checkin to the 1.0 trunk
Attachment #72967 -
Flags: approval+
Updated•22 years ago
|
Attachment #71679 -
Attachment is obsolete: true
Updated•22 years ago
|
Attachment #72025 -
Attachment is obsolete: true
Comment 48•22 years ago
|
||
patch in trunk, marking FIXED. Thanks Denis!
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Comment 49•22 years ago
|
||
I dont know the end result of the changes, either working better for, or breaking compatability with object tags, I'm assuming the former, but what I wanna ask, is if this happens to fall under something that affects websites that needs to be marked a 'relnote' item? For the next release 1.0. Or is that for bug 111648.
*** Bug 64209 has been marked as a duplicate of this bug. ***
Comment 52•22 years ago
|
||
*** Bug 146462 has been marked as a duplicate of this bug. ***
Comment 53•22 years ago
|
||
Can someone please explain what these changes actually did? And why after they were applied, the following OBJECT tag doesn't work? <OBJECT id="clientApplet" classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93" width="300" height="300" align="baseline"> <PARAM NAME="code" VALUE="LiveConnect.class"> <PARAM NAME="type" VALUE="application/x-java-applet;version=1.3"> <PARAM NAME="archive" VALUE="export.jar"> <PARAM NAME="scriptable" VALUE="true"> <PARAM NAME="mayscript" VALUE="true"> </PARAM> </OBJECT>
Comment 54•22 years ago
|
||
That HTML synatx is for an ActiveX control because of the classid. Unless you have the ActiveX plugin, Mozilla rejects those kinds of tags. It is not good to have hard-coded ActiveX classids in the Mozilla source.
Comment 55•22 years ago
|
||
The documentation on the sun site specifically gives these examples as to how to use the OBJECT tag with the java plugin... so what is the syntax to properly use the OBJECT tag to display an applet given that every Sun example uses a hardcoded clsid?
Comment 56•22 years ago
|
||
The Sun engineers think that the OBJECT tag support is supposed to be removed. It's good to see confirmation. I filed a bug at Sun about the misdocumentation on their web pages about the OBJECT tag. Assuming I'm correctly representing the opinions of all parties here: (*) There is no OBJECT tag support in Mozilla (*) Whatever support there is for the OBJECT tag in Netscape 6 can be expected to disappear. The behavior of Mozilla 1.1 is now such that the OBJECT tag cannot be used to run applets. The EMBED and APPLET tag can be used. Sun documents two versions of EMBED tags: one for dynamic versioning and the other for static versioning. Dynamic versioning is supposed to prompt the user to download a new Java JRE if her current version is older than the version specified on the tag. Static versioning is supposed to prompt the user to download a new Java JRE if her current version mismatches the version specified on the EMBED tag. I have not verified the versioning behavior of the EMBED tag, only whether an applet runs at all. Active X object with dynamic versioning Does not work and should not, despite the Sun documentation =========================================================== <object codetype="application/java" classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93" width="400" height="50" align="baseline" codebase="http://java.sun.com/products/plugin/autodl/jinstall-1_4_0-win32.cab"> Mozilla object tag support is not the same as IE's. <param name="code" value="HelloSwingApplet1.class"> <param name="type" value="application/x-java-applet;version=1.3"> </object> Netscape object tag Does not work and should not. Never documented =============================================== <object codetype="application/java" classid="java:HelloSwingApplet1.class" width="400" height="50" align="baseline"> IE's object tag support is not the same as Mozilla's. </object> Active X object with static versioning Does not work and should not, despite the Sun documentation =========================================================== <object codetype="application/java" classid="clsid:CAFEEFAC-0014-0000-0000-ABCDEFFEDCBA" width="400" height="50" align="baseline" codebase="http://java.sun.com/products/plugin/autodl/jinstall-1_4_0-win32.cab"> Mozilla object tag support is not the same as IE's. <param name="code" value="HelloSwingApplet1.class"> <param name="type" value="application/x-java-applet;jpi-version=1.4"> </object> Embed tag with dynamic versioning. Works It is possible that the "dynamicity" is Sun misdocumentation ============================================================ <embed type="application/x-java-applet;version=1.4" width="400" height="50" align="baseline" pluginspage="http://java.sun.com/products/plugin/autodl/jinstall-1_4_0-win32.cab" code="HelloSwingApplet1"> </embed> Embed tag with static versioning. Works It is possible that the "static-ness" is Sun misdocumentation ============================================================= <embed type="application/x-java-applet;jpi-version=1.4" width="400" height="50" align="baseline" pluginspage="http://java.sun.com/products/plugin/autodl/jinstall-1_4_0-win32.cab" code="HelloSwingApplet1"> </embed> Applet tag. Works ================== <applet width="400" height="50" align="baseline" code="HelloSwingApplet1.class"> </applet>
Comment 57•22 years ago
|
||
IIRC, according Sun, <OBJECT classid="clsid:..."> is for windows only and <EMBED> tag is for Solaris/*nix. If you want crossplatform behaviour, put <EMBED> tag inside of <OBJECT>. Mozilla's support of java plugin classid was a hack, that's why it removed (classid value was hardcoded in sources. hardcoding yet another new value of classid in sources is a really bad idea, isn't it?) Also note, that <OBJECT> tar with classid="java:..." still (should be) supported. (At least it was few monthes ago, when I last time worked on oji code :-) )
Comment 58•22 years ago
|
||
So... does the following work in Mozilla? <object type="application/x-java-applet;jpi-version=1.4" width="400" height="50" data="myClass.class"> </object> If it does not, then we have a problem, do we not?
Reporter | ||
Comment 59•22 years ago
|
||
No, object tag support should be removed for Mozilla. This is the whole story of this bug.
Comment 60•22 years ago
|
||
Why? <embed> and <applet> are both deprecated. I realize that you do not want to be keying off the clsid, but what's wrong with keying off the content-type like all other plugins do? And I sincerely hope you are talking about the java plugin only and not implying that we should remove <object> support completely....
Reporter | ||
Comment 61•22 years ago
|
||
You are right. What I mean is object tag support for java plugin.
Comment 62•22 years ago
|
||
OK. The question remains. Why?
Comment 63•22 years ago
|
||
OK, so EMBED isn't in the standard, APPLET is deprecated, and OBJECT support isn't in Mozilla. So please explain how I display a Java applet on a web page?
Reporter | ||
Comment 64•22 years ago
|
||
The reason why we remove object tag support for applet is because Mozilla did the wrong thing. Also to support object tag, Mozilla needs to do more than what currently we need to do. So we decide to remove that support. Applet tag and embed tag is fine to use for displaying applet although one is deprecated and the other is not in the standard.
Comment 65•22 years ago
|
||
I'm reopening this bug. This is WRONG. We are a standards compliant browser and we have no standards compliant way to display a Java applet. Checking this in was the wrong decision.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Comment 66•22 years ago
|
||
No, no, no!!! Mozilla should COMPLETLY support the OBJECT tag for Java. APPLET and EMBED are deprecated and are not able to work in all kinds of markup. The OBJECT tag is VERY important becuase it's needed for XHTML. It's too hokey to change namespaces to HTML to use the APPLET tag. And besides, the W3C has deprecated the APPLET tag for standard HTML and the EMBED tag is totally non-standard. Sun's documentation may need to be updated to show the correct way to use the OBJECT tag in Mozilla and follow W3C standards. This bug was ONLY about removing the IE-only Active-X syntax Java **HACK** CLASSID suppport in Mozilla for the OBJECT tag. If Mozilla sees a CLASSID attribute with a UUID that looks like an ActiveX control, we will IGNORE the whole tag and render contents. Instead, we now follow the W3c specs, which also support Java: http://www.w3.org/TR/html401/struct/objects.html#h-13.1 Following these specs, it's simple to use Java with the OBJECT tag. If you really need to support ActiveX, I suggest nesting OBJECT tags. This testcase that I attached shows how to use the OBJECT tag correctly with a specific Java version. The TYPE attribute needs to include the EXACT mime-type that Java registers and can be viewed in about:plugins. Boris' example has an incorrect mime-type. The correct type which works is: application/x-java-applet;jpi-version=1.4.0_01 If there are other problems in using the OBJECT tag with Java, rather than using this bug, PLEASE open NEW bugs for each issue with a detailed explaination and simplified testcases showing the problems. Thanks!
Comment 67•22 years ago
|
||
Marking FIXED again. We are not going to support hard-coded ActiveX classids in Mozilla souce. The tecase attached shows that this bug does not prevent using the OBJECT tag with following W3C standards.
Comment 68•22 years ago
|
||
Peter, thank you for the clarification. That's exactly what I was hoping to hear. Now could we please update any documents that have information similar to comment 59 and replace them with documents that have information from comment 66, including the correct MIME type (I assume that if people want support from the 1.3x java plugin they will need two nested <object> tags?). The impression created by Xiaobin's comments in this bug is very misleading and very negative... If there is any way I can help in rectifying the documentation problem we have here, please let me know.
Comment 69•22 years ago
|
||
cc:ing Ian for updating documentation of OBJECT tag use with Java Also I spoke with Patty and she will be updating the Mozilla OJI Java testcases to correctly use the OBJECT tag here: http://www.mozilla.org/quality/browser/front-end/testcases/oji/objecttests.html
Comment 70•22 years ago
|
||
Well it is too bad that the testcase crashes the latest build of Mozilla. I'm using build 2002071008 on Win2k (SP2sr1) and have Sun j2sdk1.4.0_01 installed. When I attempt to load the testcase ( http://bugzilla.mozilla.org/attachment.cgi?id=90799&action=view ) the JVM loads but, before Mozilla can display anything, it crashes. I have other applets that use the <applet> and the <embed> tag that work fine, so it most likely isn't an issue with the way I have things set up. Also, the testcase loads up just fine in IE6.0. Talkback ID: TB8194721E I haven't tested this in Mozilla 1.0 or Netscape 7.0pr1 and don't have Linux handy to test with. Maybe someone else can check those out. Also, if this is known, can someone direct me to that bug, otherwise let me know if I should file a new bug on this issue. I really hope this is only a current trunk problem because no one is going to be able to use the <object> tag for applets if it was released with Mozilla 1.0 for fear of crashing peoples browsers. Jake
Comment 71•22 years ago
|
||
What about Sun's usage documentation also?
Comment 72•22 years ago
|
||
I just read thru this bug, as I was following another bug, which referenced this, and I must admit I am somewhat confused. Mozilla has often use the object test suite ( http://www.student.oulu.fi/~sairwas/object-test/ ) for test case implantation of objects. This current solution will fail such a test case. Also from what I understand an example on the W3C site ( http://www.w3.org/TR/REC-html40/struct/objects.html#h-13.3.3 ) will also fail to work. Or am I just wrong. If I am right I would assume many would be lost on what is the correct form that will work in all browser an all platforms.
Comment 73•22 years ago
|
||
Incident ID 8194721 Stack Signature MSVCRT.DLL + 0x13541 (0x78013541) b5b73311 Email Address hoju@visi.com Product ID MozillaTrunk Build ID 2002071008 Trigger Time 2002-07-10 18:14:11 Platform Win32 Operating System Windows NT 5.0 build 2195 Module MSVCRT.DLL URL visited http://bugzilla.mozilla.org/attachment.cgi?id=90799&action=view User Comments Mozilla bombed upon viewing a testcase supposedly proving that Mozilla supports loading applets through the object tag. I have Java 1.4.0_01 installed and the applet loads just peachy with IE6.0. However, I get this crash in Mozilla just after the JVM loads up. Jake Trigger Reason Access violation Source File Name Trigger Line No. Stack Trace MSVCRT.DLL + 0x13541 (0x78013541) MSVCRT.DLL + 0x1310d (0x7801310d) MSVCRT.DLL + 0x3096 (0x78003096) nsPluginHostImpl::TrySetUpPluginInstance [c:/builds/seamonkey/mozilla/modules/plugin/base/src/nsPluginHostImpl.cpp, line 4090] nsPluginHostImpl::SetUpPluginInstance [c:/builds/seamonkey/mozilla/modules/plugin/base/src/nsPluginHostImpl.cpp, line 3895] nsPluginHostImpl::InstantiateEmbededPlugin [c:/builds/seamonkey/mozilla/modules/plugin/base/src/nsPluginHostImpl.cpp, line 3569] nsObjectFrame::InstantiatePlugin [c:/builds/seamonkey/mozilla/layout/html/base/src/nsObjectFrame.cpp, line 1275] nsObjectFrame::Reflow [c:/builds/seamonkey/mozilla/layout/html/base/src/nsObjectFrame.cpp, line 1131] nsBlockReflowContext::DoReflowBlock [c:/builds/seamonkey/mozilla/layout/html/base/src/nsBlockReflowContext.cpp, line 570] nsBlockReflowContext::ReflowBlock [c:/builds/seamonkey/mozilla/layout/html/base/src/nsBlockReflowContext.cpp, line 348] nsBlockFrame::ReflowFloater [c:/builds/seamonkey/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 5341] nsBlockReflowState::FlowAndPlaceFloater [c:/builds/seamonkey/mozilla/layout/html/base/src/nsBlockReflowState.cpp, line 886] nsBlockReflowState::AddFloater [c:/builds/seamonkey/mozilla/layout/html/base/src/nsBlockReflowState.cpp, line 686] nsLineLayout::ReflowFrame [c:/builds/seamonkey/mozilla/layout/html/base/src/nsLineLayout.cpp, line 1130] nsBlockFrame::ReflowInlineFrame [c:/builds/seamonkey/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 3807] nsBlockFrame::DoReflowInlineFrames [c:/builds/seamonkey/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 3633] nsBlockFrame::DoReflowInlineFramesAuto [c:/builds/seamonkey/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 3523] nsBlockFrame::ReflowInlineFrames [c:/builds/seamonkey/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 3468] nsBlockFrame::ReflowLine [c:/builds/seamonkey/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 2617] nsBlockFrame::ReflowDirtyLines [c:/builds/seamonkey/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 2261] nsBlockFrame::Reflow [c:/builds/seamonkey/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 952] nsBlockReflowContext::DoReflowBlock [c:/builds/seamonkey/mozilla/layout/html/base/src/nsBlockReflowContext.cpp, line 570] nsBlockReflowContext::ReflowBlock [c:/builds/seamonkey/mozilla/layout/html/base/src/nsBlockReflowContext.cpp, line 348] nsBlockFrame::ReflowBlockFrame [c:/builds/seamonkey/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 3229] nsBlockFrame::ReflowLine [c:/builds/seamonkey/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 2483] nsBlockFrame::ReflowDirtyLines [c:/builds/seamonkey/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 2261] nsBlockFrame::Reflow [c:/builds/seamonkey/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 952] nsContainerFrame::ReflowChild [c:/builds/seamonkey/mozilla/layout/html/base/src/nsContainerFrame.cpp, line 830] CanvasFrame::Reflow [c:/builds/seamonkey/mozilla/layout/html/base/src/nsHTMLFrame.cpp, line 570] nsBoxToBlockAdaptor::Reflow [c:/builds/seamonkey/mozilla/layout/xul/base/src/nsBoxToBlockAdaptor.cpp, line 886] nsBoxToBlockAdaptor::DoLayout [c:/builds/seamonkey/mozilla/layout/xul/base/src/nsBoxToBlockAdaptor.cpp, line 627] nsBox::Layout [c:/builds/seamonkey/mozilla/layout/xul/base/src/nsBox.cpp, line 1062] nsScrollBoxFrame::DoLayout [c:/builds/seamonkey/mozilla/layout/xul/base/src/nsScrollBoxFrame.cpp, line 394] nsBox::Layout [c:/builds/seamonkey/mozilla/layout/xul/base/src/nsBox.cpp, line 1062] nsContainerBox::LayoutChildAt [c:/builds/seamonkey/mozilla/layout/xul/base/src/nsContainerBox.cpp, line 649] nsGfxScrollFrameInner::LayoutBox [c:/builds/seamonkey/mozilla/layout/html/base/src/nsGfxScrollFrame.cpp, line 1086] nsGfxScrollFrameInner::Layout [c:/builds/seamonkey/mozilla/layout/html/base/src/nsGfxScrollFrame.cpp, line 1245] nsGfxScrollFrame::DoLayout [c:/builds/seamonkey/mozilla/layout/html/base/src/nsGfxScrollFrame.cpp, line 1094] nsBox::Layout [c:/builds/seamonkey/mozilla/layout/xul/base/src/nsBox.cpp, line 1062] nsBoxFrame::Reflow [c:/builds/seamonkey/mozilla/layout/xul/base/src/nsBoxFrame.cpp, line 1004] nsGfxScrollFrame::Reflow [c:/builds/seamonkey/mozilla/layout/html/base/src/nsGfxScrollFrame.cpp, line 783] nsContainerFrame::ReflowChild [c:/builds/seamonkey/mozilla/layout/html/base/src/nsContainerFrame.cpp, line 830] ViewportFrame::Reflow [c:/builds/seamonkey/mozilla/layout/html/base/src/nsViewportFrame.cpp, line 577] IncrementalReflow::Dispatch [c:/builds/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp, line 944] PresShell::ProcessReflowCommands [c:/builds/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp, line 6449] ReflowEvent::HandleEvent [c:/builds/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp, line 6303] PL_HandleEvent [c:/builds/seamonkey/mozilla/xpcom/threads/plevent.c, line 597] PL_ProcessPendingEvents [c:/builds/seamonkey/mozilla/xpcom/threads/plevent.c, line 530] _md_EventReceiverProc [c:/builds/seamonkey/mozilla/xpcom/threads/plevent.c, line 1078] nsAppShellService::Run [c:/builds/seamonkey/mozilla/xpfe/appshell/src/nsAppShellService.cpp, line 452] main1 [c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1472] main [c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1808] WinMain [c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1826] WinMainCRTStartup() KERNEL32.DLL + 0xd326 (0x77e8d326)
Comment 74•22 years ago
|
||
I am an application developer. My question is: how an OBJECT tag that is supposed to work in Mozilla, IE and be "HTML 4.01 Strict" compliant should look?
Comment 75•22 years ago
|
||
ooo....that last testcase I attached crashes in recent builds. :( It's a regression I caused with bug 152334. Like I said before, PLEASE open new bugs on new isssues. I just opened bug 156936 on this new crash with my testcase. A patch to fix the crash is already posted there.
Comment 76•22 years ago
|
||
I simplified Peter's test case (see below), and it seemed working on Windows and Linux, with moz1.0, Netscape7.0pr1 and JRE 1.4.0_01 and 1.4.1. Test HTML file: <html> <head> <title>Applet Object Tag Test</title> </head> <body> <center> <h1>Applet Object Tag Test</h1> <object type="application/x-java-applet" code=Helloworld.class WIDTH= 50% HEIGHT = 100> </object> </center> </body> </html> Test applet code, Helloworld.java: import java.applet.*; import java.awt.*; public class Helloworld extends Applet { public void paint(Graphics g) { g.drawString("Hello World from Java", 25, 50); } }
Comment 77•22 years ago
|
||
*** Bug 138315 has been marked as a duplicate of this bug. ***
Comment 78•22 years ago
|
||
Verified on windows 2k (jre 1.4.0_01), linux (jre 1.3.1.-02) (netscape branch build: 2002-07-17-08-1.0.0). It displays errors in the java console window for the mac os x. Will file a bug for mac os x separately.
Status: RESOLVED → VERIFIED
Comment 79•22 years ago
|
||
[This comment is a historical followup.] In comment 58, the question was raised about this tag format: <object type="application/x-java-applet" width="400" height="50" data="myClass.class"> </object> This would be the expected remapping of the old <EMBED> tag for the Sun-plug-in to <OBJECT>. In fact, this format does not work; however, substituting the 'data' attribute with a 'code' attribute DOES work to load the plug-in and execute the applet. (See the previously attached testcase dated 2002-07-10.) 'code' is not a standard attribute of <OBJECT>. However, this nonstandard support is available (under Windows) for at least Netscape 4 (but not 3), Mozilla, IE5-6, and Opera 6. With variations on 'type', the format is also supported by Opera 5 and HotJava 3. It should also work for the Linux versions of these browsers with the Sun plug-in; and perhaps also for some Mac browsers, as the MRJPlugin associates itself with application/x-java-applet, and Jaguar has an implementation of the Sun Java Plug-in. As noted in the discussion above, <OBJECT classid="java:appletname" ...> is as standard a format for Java applets as we have. This format is widely supported by modern browsers, including IE5 for the Mac. Netscape 4, and IE 6 for Windows, both have some support for this tag: both only use the down-rev "integrated" JVMs, and each is somewhat broken in its own way. The only advantage to the 'code' format of <OBJECT> is that the 'type' can be used to specify a particular version of plug-in, and so decline to render if that version is unavailable; if <OBJECT>'s 'classid' contains "java:", Mozilla reasonably ignores the codetype/type attributes, and uses the OJI plugin.
Comment 80•22 years ago
|
||
I am a Java application developer, trying to get applets to work in IE and Moz. I recently filed a bug report (http://bugzilla.mozilla.org/show_bug.cgi?id=173140) claiming that Moz does not support the <object> tag for Java applets. My recent experiments with the feedback from that post do NOT leave me convinced that Moz fully supports this. Since one person there pointed me to this bug report, I am directing my comments here. My claim is that for Moz to support modern Java applets via the <object> tag, it must have the following characteristics: 1) a single <object> tag (including <param> child tags) specifies everything 2) it must support applet code being located inside a jar file 3) there must be a way to specify a specific JVM version to use 4) it would be really nice if this JVM specification supported both dynamic versioning (e.g. if a 1.3 JVM was specified but the user has a 1.4 JVM, then that is OK and the 1.4 JVM will be used) and static versioning (the exact JVM specified must be used); see http://java.sun.com/products/plugin/versions.html 5) if a satisfactory JVM is not present, then the <object> tag will have an attribute with a URL value that the user can download the JVM from 6) the "scriptable" property of the applet must be specifiable 7) archive caching must be specifiable (see http://java.sun.com/j2se/1.3/docs/guide/misc/appletcaching.html) 8) the html file must validate against the strict html 4.01 dtd (as well as xhtml) 9) the solution works under both IE and Moz If anyone can post an html fragment that shows ALL of the above in action and working, then I would be very grateful and I will gladly retract my claim that Moz does not fully support the <object> tag for Java applets. The existing code samples that people have posted are too simple, and never show all the above in action. Until this is done, this bug should NOT be closed. Consider this html fragment: <object classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93" codebase="http://java.sun.com/products/plugin/1.4/jinstall-14-win32.cab#Version=1,4,0,mn" width="250" height="400" style="vertical-align: baseline;"> <!-- Specify the Applet class to use: --> <param name="code" value="FastAnimationApplet.class"> <param name="codebase" value="./"> <param name="archive" value="./animationResources.jar"> <!-- Specify other features about the Applet: --> <param name="type" value="application/x-java-applet;jpi-version=1.4"> <param name="scriptable" value="false"> <!-- Specify archive caching (see http://java.sun.com/j2se/1.3/docs/guide/misc/appletcaching.html): --> <param name="cache_option" value="No"> <param name="cache_archive" value="./animationResources.jar"> <!-- Specify below stuff specific to the Applet in use: --> <param name="someName" value="someValue"> <!-- etc etc --> <!-- Text to display if Java not supported: --> A Java applet should be here, but it could not be displayed. Possible causes include: <ul> <li>your browser does not support Java 2 SDK Standard Edition v 1.4.0</li> <li>Java support has been disabled</li> <li>an internal error occurred</li> </ul> </object> I believe that this code satisfies all of the above conditions except for 9): it only works in IE. (Well, I have not exactly tested some of the conditions like 3) thru 7), and am simply trusting the documentation that they work; see: http://java.sun.com/j2se/1.4/docs/guide/plugin/developer_guide/using_tags.html http://java.sun.com/j2se/1.3/docs/guide/misc/appletcaching.html http://java.sun.com/products/plugin/versions.html ) If I understand the discussion in this bug report correctly, the above does not work in Moz because the classid used there acutally specifies an ActiveX plugin, which does Moz does not support; and an old attempt in Moz to map ActiveX classids into Netscape plugins ultimately failed. OK. So why doesn't Moz simply ignore classids and instead have the JVM simply be specified by adding a type attribute inside the <object> tag like type="application/x-java-applet;jpi-version=1.4" ? It would would be so nice if that were all it took to get stuff to work in Moz. IE seems to completely ignore type attributes, so there would be no interference. Instead, to get things to work in Moz, I found that not only do I need to add the above type attriubute, but I also need to rip out the classid attribute. Other than that, it appears that EVERYTHING ELSE CAN STAY THE SAME. (In particular, you do not need to specify stuff like code/data and archive as attributes in the <object> tag, which everybody else seems to want to do, but can instead do it IE style as <param> tags; I suspect that this has nothing to do with Moz but is because sun's AppletViewer class supports this, so as long as it is launched then everything is fine.) Here is a fragment that works in my Moz 1.1 with my JDK 1.4.0_01: <object type="application/x-java-applet;jpi-version=1.4.0_01" codebase="http://java.sun.com/products/plugin/1.4/jinstall-14-win32.cab#Version=1,4,0,mn" width="250" height="400" style="vertical-align: baseline;"> <!-- Specify the Applet class to use: --> <param name="code" value="FastAnimationApplet.class"> <param name="codebase" value="./"> <param name="archive" value="./animationResources.jar"> <!-- Specify other features about the Applet: --> <param name="type" value="application/x-java-applet;jpi-version=1.4"> <param name="scriptable" value="false"> <!-- Specify archive caching (see http://java.sun.com/j2se/1.3/docs/guide/misc/appletcaching.html): --> <param name="cache_option" value="No"> <param name="cache_archive" value="./animationResources.jar"> <!-- Specify below stuff specific to the Applet in use: --> <param name="someName" value="someValue"> <!-- etc etc --> <!-- Text to display if Java not supported: --> A Java applet should be here, but it could not be displayed. Possible causes include: <ul> <li>your browser does not support Java 2 SDK Standard Edition v 1.4.0</li> <li>Java support has been disabled</li> <li>an internal error occurred</li> </ul> </object> Does anyone know if condition 5) is satisfied by Moz (i.e. that it will goto http://java.sun.com/products/plugin/1.4/jinstall-14-win32.cab#Version=1,4,0,mn and download the plugin if necessary)? And that conditions 6) ("scriptable") and 7) (archive caching) are supported? Also, for condition 4), http://java.sun.com/products/plugin/versions.html indicates that with the old embed tag dynamic versioning and static versioning are achieved by using the type "application/x-java-applet;version=..." and "application/x-java-applet;jpi-version=..." respectively. Does this hold true here as well? It does not seem to for me: when I tried using just "application/x-java-applet;version=..." it asked me to download a plugin; this is bad, as dynamic versioning is what is typically most useful. Regardless, the ripping out of the classid has the disastrous effect that it no longer works in IE. This is completely unsatisfactory! If you would follow my suggestion above (have Moz ignore the classid in this case since it does not support it, and instead use the type attribute which IE seems to ignore) then I believe that both Moz and IE could be gotten to work with a single <object> tag. I beg of you to reconsider this as I really like Mozilla and would love to see it be supported, but I am NOT going to go thru oppressive hoops like have multiple versions of files, use multiple embedded <object> tags, etc. I believe that most programmers are going to have even less patience than me with supporting Moz. p.s. here are some of the relevant bug reports: http://bugzilla.mozilla.org/show_bug.cgi?id=173140 http://bugzilla.mozilla.org/show_bug.cgi?id=46569 http://bugzilla.mozilla.org/show_bug.cgi?id=108557
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Comment 81•22 years ago
|
||
Looking over nsObjectFrame::Reflow, it looks like Brent's suggestion (which I wholeheartedly support, btw, unless someone has a _really_ good reason why we should not implement it) would not be that hard to do. We'd just need to make the "not java object or internal widget and we have no ActiveX handler" case fall through to "no classid attribute" code...
Comment 82•22 years ago
|
||
Boris, thanks for the support! It is good to see that I am not the only one up slaving away at 2:40 am... If this is ever gotten to work, then Sun's docs as well as the W3C docs have to be brought up to date. I assume that someone here knows the relevant people in these organizations to contact? I have appealed to the W3C in the recent past to update the html spec (http://www.w3.org/TR/html401/struct/objects.html) on this matter, and have only met with silence.
Comment 83•22 years ago
|
||
open a new bug for your suggestion. This bug is about removing a hard-coded constant and has been fixed for a long time. However, I don't see the problem of using the same tag. The following markup gets Java easily working in both browsers: http://www.mozilla.org/quality/browser/front-end/testcases/oji/objecttest1.html <object codebase="." classid="java:JitterText.class" width=400 height=80 align=left border=0> <param name=BGCOLOR value="000000"> <param name=TEXTCOLOR value="FF0000"> <param name=TEXT value="OJITesting!"> <param name=SPEED value="250"> <param name=RANDOMCOLOR value=1> </object> It even works with the TYPE attribute. If Gecko just ignored the CLASSID attribute, we'd run into problems in determining what CODEBASE is used for. Microsoft in the ActiveX world uses CODEBASE to refer to where to download the Java plugin CAB installer while the W3C spec (and Gecko) understand CODEBASE to meam the base URL for the 'code'.
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → FIXED
Comment 84•22 years ago
|
||
As per Peter's suggestion, I have filed a new bug report; see http://bugzilla.mozilla.org/show_bug.cgi?id=178780
You need to log in
before you can comment on or make changes to this bug.
Description
•