Last Comment Bug 452204 - 'base href' and 'applet' tag misusage
: 'base href' and 'applet' tag misusage
Status: UNCONFIRMED
:
Product: Core
Classification: Components
Component: Plug-ins (show other bugs)
: Trunk
: x86 Windows XP
: -- normal with 5 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-08-26 02:37 PDT by Ralf Hoops
Modified: 2011-02-04 14:31 PST (History)
9 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Ralf Hoops 2008-08-26 02:37:27 PDT
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1

Assuming load a html-page at url "https://z7014.net:8181/z/task/taskLaunch.jsp" with the following excerpt:
...
<BASE HREF="https://z7014.net:8181/z/">
...
  <APPLET name="resourceObject.attributes.dwpWP2TCName" CODEBASE="applet/" archive="ms6.jar" CODE="com.waveset.ui.web.applet.multiselect.class" WIDTH="400" HEIGHT="150" HSPACE="0" VSPACE="0" ALIGN="middle" MAYSCRIPT>
...

will lead to an logentry in the java console like
network: Verbindung https://z7014.net:8181/z/task/applet/ms6.jar mit Cookie "JSESSIONID=fe1c1f4115cfb26cf69e7231ea5de"
java.io.FileNotFoundException: https://z7014.net:8181/z/task/applet/ms6.jar


but the class/archive can only be found using the 'base href' tag correctly. With IE an older releases of firefox you will get
network: Cache-Eintrag nicht gefunden [url: https://z7014.net:8181/z/applet/ms6.jar, Version: null]
network: Verbindung von https://z7014.net:8181/z/applet/ms6.jar mit Proxy=DIRECT wird hergestellt



Reproducible: Always

Steps to Reproduce:
1. Load html-page with an applet and an base href tag where the locations differ
2.
3.
Actual Results:  
Finding in the protocol of the java control panel

network: Verbindung https://z7014.net:8181/z/task/applet/ms6.jar mit Cookie "JSESSIONID=fe1c1f4115cfb26cf69e7231ea5de"
java.io.FileNotFoundException: https://z7014.net:8181/z/task/applet/ms6.jar


Expected Results:  
Finding in the protocol of the java control panel

network: Cache-Eintrag nicht gefunden [url: https://z7014.net:8181/z/applet/ms6.jar, Version: null]
network: Verbindung von https://z7014.net:8181/z/applet/ms6.jar mit Proxy=DIRECT wird hergestellt


html-page

...
<BASE HREF="https://z7014.net:8181/z/">
...
  <APPLET name="resourceObject.attributes.dwpWP2TCName" CODEBASE="applet/" archive="ms6.jar" CODE="com.waveset.ui.web.applet.multiselect.class" WIDTH="400" HEIGHT="150" HSPACE="0" VSPACE="0" ALIGN="middle" MAYSCRIPT>
...
Comment 1 Adam Roberson 2008-11-05 13:25:56 PST
This problem only seems to occur in Firefox 3 with JRE 1.6.0_10 on a Windows machine.  The applet HTML is being generated by calling a java script function which looks like the following.

function createControl(name,

                       codebase,

                       archive,

                       code,

                       width,

                       height,

                       hspace,

                       vspace,

                       align,

                       alt,

                       params) {



    var html =

        '<applet name=\'' + name + '\' ' +

        'codebase=\'' + codebase + '\' ' +

        'archive=\'' + archive + '\' ' +

        'code=\'' + code + '\' ' +

        'width=\'' + width + '\' ' +

        'height=\'' + height + '\' ' +

        'hspace=\'' + hspace + '\' ' +

        'vspace=\'' + vspace + '\' ' +

        'align=\'' + align + '\' ' +

        'alt=\'' + alt + '\' mayscript>' +

        params +

        '</applet>';

    document.write(html);

}

codebase is set to the applet/ directory and expects the browser to use the Base Href to fill in the rest of the code base.  However the applet code base in the java console shows the code base as the current page 
http://localhost:8080/idm/account/applet/com/waveset/ui/web/applet/multiselect/class.class instead of the proper base href plus passed in code base of
http://localhost:8080/idm/applet/com/waveset/ui/web/applet/multiselect/class.class

The base href is set to http://localhost:8080/idm/.  If this is not fixed, we will be forced to state that we do not support Firefox 3 on the current release.  If you disable the next generation java plugin then firefox 3 works according to firefox 2 rules and displays the applets.
Comment 2 Volkan 2009-02-18 03:22:27 PST
Hi,

I've checked to see that this bug affects all of the following platforms:
- Java 6 Update 11 (build 1.6.0_11-b03) on Windows Vista 32 bit
---> Firefox 3.0.6, Safari 3.2.1 (525.27.1), Google Chrome 1.0.154.48

- OpenJDK IcedTea1.4 with Fedora C10 32 bit 
---> Firefox 3.0.5

Apparently all of these browsers should change their behaviour, or Sun Identity Manager should change theirs. 

Since BASE HREF tag isn't honored while rendering the APPLET tag, the burden seems to be on the BROWSER side, not on Sun Identity Manager side.

Actually this bug(?) is prone to cause huge headaches in enterprise environments.

Best,
Volkan
Comment 3 John Tkaczewski 2009-02-24 09:16:33 PST
We have a web application that loads applets using Struts actions. All applets are now failing when we use a struts action to load the applet. 
Struts action use a &lt;base> tag  to point to the correct JSP and all our JAR files are now in the same folder as the JSP page. We need re-design how we store the JAR files for the applets to 'workaround' this bug. 

I confirmed this bug in Firefox 3.0.6 and Java 1.6.0_11-b03
Comment 4 Baaf 2009-03-04 05:02:30 PST
I'm using Sun's Identity Manager 8.0 it uses Applets for certain parts of webpages. I can confirm that under Windows 2003, IE 7 it works and for Firefox 3.0.6 it doesn't. I'm using Java 6 update 12.
Comment 5 Martin 2009-04-07 05:46:13 PDT
I see the same problem with Firefox 3.5 on Linux (Ubuntu Jaunty) platform. The ieActiveXFix.js fix described above doesn't work, because the applet tag isn't generated there for this platform (I guess).
Comment 6 Kirsten Coppo 2009-04-29 10:41:29 PDT
Does any one have a workaround for this issue?  Or how do you backout the Firefox and Java for windows?
Comment 7 AnimalFriend 2009-05-04 06:48:19 PDT
They work with FireFox using the old plugin (but same Java version). It fails using the new Plugin.

The applets render fine on IE6 using JDK1.6_13 and the New Java Plugin. Sadly, I cannot activate the old plugin under IE6 anymore (crashes).

The Java plugin to use is a configurable setting in the "Advanced" tab of the Java Control Panel applet.

I am not sure whether this is a problem in FireFox, since it is working correctly with the same setup but the old Plugin.

I am using:
Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10 (.NET CLR 3.5.30729)
Comment 8 timeless 2009-05-04 22:52:04 PDT
could someone please provide a useful summary? (one line, <120 chars) the current one doesn't work for me.
Comment 9 Volkan 2009-05-06 01:14:55 PDT
kirsten, two workarounds are possible:

1) 
you can set your java settings to use the old plugin. it is under:

Control Panel -> Advanced -> Java Plug-in -> Uncheck, "Enable the next-generation Java Plug-in (requires browser restart)

2)
you can rewrite your web pages code so that every applet uses the full path of the codebase/applet.

neither seems to be appropriate or at least easy to deploy however..
Comment 10 Kirsten Coppo 2009-05-06 09:16:40 PDT
We are using Sun's Idm system so re-coding isn't possible.
What I am finding is that different versions of JAVA have different control panels and options.  I couldn't install the lastest JAVA which I think is your intructions. I have version 6, update 7.  So by playing with the adavanced options, I unchecked Default Java for browsers-Mozilla family and that seem to work.
Comment 11 Volkan 2009-11-12 05:34:03 PST
This bug is still in effect at version 3.6 beta 2. I have proven that BASE HREF tag isn't taken into account by using FireBug. When I set change the codebase to the full path, applets run smooth as silk whereas in the current form, I get the following error and even the workaround, i.e. disabling "Next Generation Plugin" can't fix this problem at version 3.6 beta 2.

Exception: java.lang.ClassFormatError: Incompatible magic value 1008813135 in class file com/waveset/ui/web/applet/multiselect
java.lang.ClassFormatError: Incompatible magic value 1008813135 in class file com/waveset/ui/web/applet/multiselect
	at java.lang.ClassLoader.defineClass1(Native Method)
	at java.lang.ClassLoader.defineClass(Unknown Source)
	at java.security.SecureClassLoader.defineClass(Unknown Source)
	at sun.plugin2.applet.Applet2ClassLoader.findClass(Unknown Source)
	at java.lang.ClassLoader.loadClass(Unknown Source)
	at java.lang.ClassLoader.loadClass(Unknown Source)
	at sun.plugin2.applet.Plugin2ClassLoader.loadCode(Unknown Source)
	at sun.plugin2.applet.Plugin2Manager.createApplet(Unknown Source)
	at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)

So please fix this bug. This is open for so long and I believe it is a very easy thing to fix.
Comment 12 Volkan 2009-11-12 06:03:29 PST
The same problem has been filed under:
https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+bug/409329

As you may read there, this usage is apparently not allowed as per the HTML4 specs since the applet should only reside in the subfolders of the current documents directory.

However, this still does not explain, why the applets work when I prepend the base uri to the codebase. 

Maybe codebase should honor the base element, and then check if the resulting url is a subfolder of the current document.
Comment 13 aravindm 2010-04-20 06:06:46 PDT
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.3a4) Gecko/20100407 MozillaDeveloperPreview/3.7a4
Please update if you are able to still reproduce with the latest nightly build  ftp://ftp.mozilla.org/pub/firefox/nightly/latest-trunk/
Comment 14 Julian Hall 2010-12-16 08:44:33 PST
Re comment 8 - a better summary might be '<applet ...> tags ignore the setting of <base href="..."> and resolve relative URLs relative to document source'

Just encountered this issue in Firefox 3.6.12, Win XP, Java 1.6.0 update 22.  The problem also seems to occur with <embed ...> tags, although I'm not certain that there's no workaround there.

The problem is also manifested in Google Chrome, so I'm guessing it's not so much a Mozilla problem as an Oracle problem.
Comment 15 Julian Hall 2010-12-16 08:49:07 PST
See also: http://code.google.com/p/chromium/issues/detail?id=12783
Comment 16 Julian Hall 2010-12-16 09:02:06 PST
Confirming observation in comment 11 that the proposed workaround no longer works. Using Java Control Panel to disable the "next generation" plugin does not in fact disable the "next generation" plugin, as it is still listed in tools/add-ons/plugins.

Note You need to log in before you can comment on or make changes to this bug.