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)

Product:
Core Graveyard
Component:
Java: OJI
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
mozilla1.0

People

(Reporter: xiaobin.lu, Assigned: peterl-bugs)

References

(
URL
)

Details

Attachments

(2 files, 6 obsolete files)

using nsCRT::strncmp this time
2.49 KB, patch
peterlubczynski-bugs
: review+
beard
: superreview+
asa
: approval+
Details | Diff | Splinter Review
testcase showing JAVA working with OBJECT tag and a specified JRE version
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.
Add stanley to cc list
*** Bug 108555 has been marked as a duplicate of this bug. ***
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
Handing off to plugins, where I think this code was created.
Assignee: attinasi → av
Component: Layout → Plug-ins
QA Contact: petersen → shrir
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
  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
Joe or Patrick:
    Would you guys mind reviewing the patch for me? Thanks in advance!

 
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+
OS: Windows NT → All
Hardware: PC → All
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...
Peter or Joe:
    Can either of you review the patch? Thank you very much!
Xiaobin
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+
clsid=java.classname is used for displaying applet. This is another form of 
object tag with clsid used around a lot.

The last patch is needed for bug 111648.

Patrick, can you sr=?
Blocks: 111648
Comment on attachment 58294 [details] [diff] [review]
Removed both clsid="THE CLASS ID" and clsid="java:className" support

sr=beard
Attachment #58294 - Flags: superreview+
What is teh status of this one?
Patch hash both r/sr. 
May be it is the time for someone to check it in?
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....
--->Reassign to Xiaobin, owner of patch.
Assignee: joe.chou → xiaobin.lu
Attached patch Patch upadted (obsolete) — — Splinter Review 

    
    

    
  
The updated patch still has lines hard-wrapped at 80 chars.  Try applying it to
a tree.... it fails.

    
    

    
  
Boris:
 Can you elaborate what hard-wrapper is?
 

    
    

    
  
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.

    
    

    
  


  
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

    
    

    
  
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...

    
    

    
  
Looks good to me. r= Xiaobin

    
    

    
  
Oh, and get driver approval (drivers@mozilla.org), please (needed for checkin
before 1.0).

    
    

    
  
Igor:
   Would you please check that patch in for me? Thanks!

Xiaobin

    
    

    
  
Xiaobin: sorry, i have no permissions to check code in myself.
         May be Peter Lubczynski can help with this.


    
    

    
  
-->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.
Assignee: xiaobin.lu → peterl
Keywords: approval, 
          
            patch
Priority: -- → P3
Summary: Mozilla should ignore object tag → Remove JAVA_CLASS_ID support for OBJECT tag
Target Milestone: --- → mozilla0.9.9

    
    

    
  
Comment on attachment 70902 [details] [diff] [review]
Updated patch without wrapped lines

(from comments)

        Attachment #70902 -
        Flags: superreview+

        Attachment #70902 -
        Flags: review+

    
    

    
  
-->back to Xiaobin to explain this bug to drivers
Assignee: peterl → xiaobin.lu

    
  

        Attachment #70902 -
        Flags: superreview+

    
    

    
  
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 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+

    
    

    
  

      
      
      
      

        Attached patch
          
          
        only remove JAVA_CLASS_ID  (obsolete)
        — 
          — Splinter Review
      

    


  
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

    
    

    
  
-->back to me
Assignee: xiaobin.lu → peterl
Keywords: approval → review

    
    

    
  
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.

    
    

    
  
Marking nsbeta1+ per ADT triage.  This bug addresses part of the problem in bug
111648.
Keywords: nsbeta1+

    
  
Blocks: 64209

    
    

    
  

      
      
      
      

        Attached patch
          
          
        get rid of classid.Cut() (obsolete)
        — 
          — Splinter Review
      

    


  
We don't need it anymore, I believe.

    
    

    
  
Comment on attachment 72025 [details] [diff] [review]
get rid of classid.Cut()

r=peterl

        Attachment #72025 -
        Flags: review+

    
    

    
  
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+

    
    

    
  
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.

    
    

    
  


  
to get sr= :-)

    
  
Target Milestone: mozilla0.9.9 → mozilla1.0

    
    

    
  
Can we get r=/sr= here again?
BTW, this bug also prevents better fix for bug #130605 :-)


    
    

    
  
Comment on attachment 72967 [details] [diff] [review]
using nsCRT::strncmp this time

r=peterl

        Attachment #72967 -
        Flags: review+

    
    

    
  
Comment on attachment 72967 [details] [diff] [review]
using nsCRT::strncmp this time

sr=beard

        Attachment #72967 -
        Flags: superreview+

    
    

    
  
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+

    
  

        Attachment #71679 -
        Attachment is obsolete: true

    
  

        Attachment #72025 -
        Attachment is obsolete: true

    
    

    
  
patch in trunk, marking FIXED.

Thanks Denis!
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED

    
    

    
  
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. ***

    
    

    
  
Verified the patch
Status: RESOLVED → VERIFIED

    
    

    
  
*** Bug 146462 has been marked as a duplicate of this bug. ***

    
    

    
  
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>


    
    

    
  
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.

    
    

    
  
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?

    
    

    
  
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>


    
    

    
  
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 :-) )

    
    

    
  
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?

    
    

    
  
No, object tag support should be removed for Mozilla. This is the whole story of
this bug.

    
    

    
  
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....

    
    

    
  
You are right. What I mean is object tag support for java plugin.

    
    

    
  
OK.  The question remains.  Why?

    
    

    
  
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?

    
    

    
  
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. 



    
    

    
  
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 → ---

    
    

    
  


  
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!

    
    

    
  
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.
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
Keywords: patch, 
          
            review
Resolution: --- → FIXED

    
    

    
  
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.

    
    

    
  
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

    
    

    
  
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



    
    

    
  
What about Sun's usage documentation also?

    
    

    
  
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.

    
    

    
  
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) 

    
    

    
  
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?

    
    

    
  
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.

    
    

    
  
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);
	}
}


    
    

    
  
*** Bug 138315 has been marked as a duplicate of this bug. ***

    
    

    
  
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

    
    

    
  
[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.

    
    

    
  
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 → ---

    
    

    
  
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...

    
    

    
  
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.

    
  
QA Contact: pmac → petersen

    
    

    
  
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

    
    

    
  
As per Peter's suggestion, I have filed a new bug report; see
    http://bugzilla.mozilla.org/show_bug.cgi?id=178780


    
  
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: