452204 - 'base href' and 'applet' tag misusage

Reporter

Description

•

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

Ralf Hoops

Reporter

Updated

•

16 years ago

Version: unspecified → 3.0 Branch

Adam Roberson

Comment 1

•

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

Volkan

Comment 2

•

15 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

John Tkaczewski

Comment 3

•

15 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

Baaf

Comment 4

•

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

Martin

Comment 5

•

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

Kirsten Coppo

Comment 6

•

15 years ago

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

AnimalFriend

Comment 7

•

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

timeless

Comment 8

•

15 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

Volkan

Comment 9

•

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

Kirsten Coppo

Comment 10

•

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

Volkan

Comment 11

•

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

Volkan

Comment 12

•

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

aravindm

Comment 13

•

14 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]

Julian Hall

Comment 14

•

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

Julian Hall

Comment 15

•

14 years ago

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

Julian Hall

Comment 16

•

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

Wayne Mery (:wsmwk)

Updated

•

13 years ago

Whiteboard: [closeme 2010-05-05]

Benjamin Smedberg

Comment 17

•

7 years ago

Resolving old bugs which are likely not relevant any more, since NPAPI plugins are deprecated.

Status: UNCONFIRMED → RESOLVED

Closed: 7 years ago

Resolution: --- → INCOMPLETE

BMO Automation

Updated

•

2 years ago

Product: Core → Core Graveyard

Bugzilla

Quick Search

'base href' and 'applet' tag misusage

Categories

(Core Graveyard :: Plug-ins, defect)

Tracking

(Not tracked)

People

(Reporter: ralf.hoops, Unassigned)

References

Details

Crash Data

Security

(public)

User Story

Description

Updated

Comment 1

Comment 2

Comment 3

Comment 4

Comment 5

Comment 6

Comment 7

Comment 8

Comment 9

Comment 10

Comment 11

Comment 12

Comment 13

Comment 14

Comment 15

Comment 16

Updated

Comment 17

Updated