'base href' and 'applet' tag misusage

RESOLVED INCOMPLETE

Status

()

Core
Plug-ins
RESOLVED INCOMPLETE
9 years ago
2 months ago

People

(Reporter: Ralf Hoops, Unassigned)

Tracking

Trunk
x86
Windows XP
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

9 years ago
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>
...
(Reporter)

Updated

9 years ago
Version: unspecified → 3.0 Branch

Comment 1

9 years ago
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

8 years ago
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

8 years ago
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

8 years ago
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

8 years ago
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

8 years ago
Does any one have a workaround for this issue?  Or how do you backout the Firefox and Java for windows?

Comment 7

8 years ago
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

8 years ago
could someone please provide a useful summary? (one line, <120 chars) the current one doesn't work for me.
Component: General → Plug-ins
Product: Firefox → Core
QA Contact: general → plugins
Version: 3.0 Branch → Trunk

Comment 9

8 years ago
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

8 years ago
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

8 years ago
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

8 years ago
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

7 years ago
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/
Whiteboard: [closeme 2010-05-05]

Comment 14

7 years ago
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

7 years ago
See also: http://code.google.com/p/chromium/issues/detail?id=12783

Comment 16

7 years ago
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.
Whiteboard: [closeme 2010-05-05]
Resolving old bugs which are likely not relevant any more, since NPAPI plugins are deprecated.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 2 months ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.