119622 - <applet> <object> codebase="" should resolve relative uri

Status: RESOLVED WORKSFORME

(Core Graveyard :: Plug-ins, defect, P3)

Description

[basic]

This worked with NS4. In an <applet> tag with codebase set to a relative url it
will resolve to an absolute url based on the document's base url.

Comment 1

[Doron Rosenberg (IBM)]

->plugins

Comment 2

[Peter Lubczynski]

-->back to default owner for triage

Reporter: A testcase showing the difference between 4.x would be very helpful!

Comment 3

[rubydoo123]

reporter: can you please point to a location where this is not working? We
resolve relative URLs already, so I am curious to see locations where we fail at
this behavior.

Comment 4

[David Campbell]

Hi,

I've just experienced this problem.  I am using mozilla 2002053012 and the java
1.4 plugin.  I have a friend who is using the same mozilla and the java 1.3 plugin.

Here's some detail:

For an applet that starts like this:

<applet align="middle" name="Main" codebase=".."
code="InfoShopWizard.Main.class" archive="InfoShopWeb/secure/InfoShopWizard.jar"
width="180" height="30">

java 1.4 plugin causes this to appear in the java console:

java.io.IOException: Server returned HTTP response code: 400 for URL:
https://localhost:16443/../InfoShopWeb/secure/InfoShopWizard.jar

see how it is trying to retrieve the jar from a url that starts with ".."

that strikes me as wrong.

this problem doesn't seem to occur in the 1.3 plugin.

Comment 5

[rubydoo123]

Using a windows build from 20020617, I created a local testcase to check this
out. Created a folder named test, nested inside test were the class files, and
nested a sub-folder called html. Inside the html folder I created an html file
with an applet tag: and set the codebase="..", the applet rendered just fine.
This should be tested on the server to verify it works fine there. Shrir: can
you try this on the server? This is what I did:

1. Went to http://java.sun.com
2. Selected "Free Applets available for use"
3. Selected the Clock
4. Selected to Download the clock, unzipped into a folder called "test"
5. Created a nested folder called html
6. When the unzip occured, there were several directories that were created.
Under "demo" is a folder named "Clock". I copied the contents of that folder
into the "test" folder.
7. Move the class files out of the classes folder so they are directly in the
test folder. Which leaves this in the test folder:
demo
html
src
and the 4 class files (AnalogClock, CustomeParser,JavaClock and ParamParser
8. In the html folder, create an html file and drop this in that file:
<applet codebase=".." code="JavaClock.class" width="150" height="150">

<param  name="delay"   value="100">
<param  name="link"    value="http://java.sun.com/">
<param  name="border"  value="5">
<param  name="nradius" value="80">
<param  name="cfont"   value="TimesRoman|BOLD|18">

<param  name="bgcolor" value="ffffff">
<param  name="shcolor" value="ff0000">
<param  name="mhcolor" value="00ff00">
<param  name="hhcolor" value="0000ff">

<param  name="ccolor"  value="dddddd">
<param  name="ncolor"  value="000000">

</applet>

Save the file and view it in the browser.

Shrir: could you replicate that test on the server?

Comment 6

[rubydoo123]

I tested this again, and noticed that they changed the site - you must now go to
http://java.sun.com/openstudio to access the class files

This is still a WFM, but have asked Shrir to test on the server

Comment 7

[rubydoo123]

The plug-ins triage team (av, beppe, peterl, serge and shrir) have reviewed this
issue and have made the following determination:

Sending to Serge for resolution

Comment 8

[shrirang khanzode]

i tested this on a local server on my box, works fine. reporter, can u pls check 
your server sttings anything to do with that? what is the web server u are 
using? marking wfm till we get a response from reporter.

Comment 9

[Robin Lionheart]

When <object> is an image or document, codebase="" is not used to resolve data="". See bug #40680.