Closed
Bug 452204
Opened 16 years ago
Closed 7 years ago
'base href' and 'applet' tag misusage
Categories
(Core Graveyard :: Plug-ins, defect)
Tracking
(Not tracked)
RESOLVED
INCOMPLETE
People
(Reporter: ralf.hoops, Unassigned)
Details
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•16 years ago
|
Version: unspecified → 3.0 Branch
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.
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•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 <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
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.
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•15 years ago
|
||
Does any one have a workaround for this issue? Or how do you backout the Firefox and Java for windows?
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)
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
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•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.
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.
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.
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]
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.
Comment 15•14 years ago
|
||
See also: http://code.google.com/p/chromium/issues/detail?id=12783
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.
Updated•13 years ago
|
Whiteboard: [closeme 2010-05-05]
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
Updated•2 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•