|
Quick Lists
|
|
Bug ID:
|
4294902
|
|
Votes
|
1
|
|
Synopsis
|
Regression: JTextPane.setPage(url) doesn't find images relative to html file
|
|
Category
|
java:classes_net
|
|
Reported Against
|
kestrel-beta
|
|
Release Fixed
|
|
|
State
|
11-Closed,
Not a Defect,
bug
|
|
Priority:
|
4-Low
|
|
Related Bugs
|
|
|
Submit Date
|
28-NOV-1999
|
|
Description
|
java version "1.3beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3
Java(TM) HotSpot Client VM (build 1.3beta-O, mixed mode)
When using a JTextPane.setPage(url) to read in an HTML file, tags like
<img SRC="image.gif"> should read image.gif relative to the location of
the HTML document. This worked correctly in JDK 1.2.2 but no longer works in
JDK 1.3beta. Instead, JDK 1.3beta looks for the image file relative to the
program class file. It appears that JDK 1.2.2 loads images using
getDocumentBase() which is correct, but JDK 1.3beta now loads images using
getCodeBase() which is incorrect.
The following test will illustrate the problem. Setting up the folders
correctly is essential for the test.
1) Create a folder called "prog". Put the file HTMLReadBug.java (below) in
"prog", and compile.
2) Inside "prog" create a subfolder "doc". Put the file test.html (below) in
"doc". Also put into "doc" the file javalogo52x88.gif (you can get a copy from
the upper left corner of http://www.javasoft.com).
3) Try java HTMLReadBug under JDK 1.2.2, open test.html, it works.
4) Try java HTMLReadBug under JDK 1.3beta, open test.html, it doesn't work.
5) Copy javalogo52x88.gif into the "prog" folder, run again under JDK 1.3beta,
now it works.
Here is HTMLReadBug.java:
import javax.swing.*;
import javax.swing.text.*;
import java.awt.*;
public class HTMLReadBug extends JApplet {
public void init() {
getRootPane().putClientProperty("defeatSystemEventQueueCheck",
Boolean.TRUE);
getContentPane().setLayout(null);
setSize(400,300);
jScrollPane1.setOpaque(true);
getContentPane().add(jScrollPane1);
jScrollPane1.setBounds(10,10,390,290);
jScrollPane1.getViewport().add(jTextPane1);
jTextPane1.setBounds(0,0,290,290);
java.awt.FileDialog openFileDialog = new java.awt.FileDialog(new
Frame());
openFileDialog.setVisible(true);
String fileName = openFileDialog.getDirectory() +
openFileDialog.getFile();
jTextPane1.setContentType("text/html");
try {
java.net.URL url = new java.net.URL("file",null,fileName);
jTextPane1.setPage(url);
}
catch (Exception e) { }
}
javax.swing.JScrollPane jScrollPane1 = new javax.swing.JScrollPane();
javax.swing.JTextPane jTextPane1 = new javax.swing.JTextPane();
// main method so can run applet as an application
static public void main(String args[]) {
class DriverFrame extends JFrame {
public DriverFrame() {
addWindowListener(new java.awt.event.WindowAdapter() {
public void windowClosing(java.awt.event.WindowEvent event) {
dispose();
System.exit(0);
}
});
this.setTitle("HTML Read Bug");
this.getContentPane().setLayout(null);
this.setSize(420,350);
HTMLReadBug applet = new HTMLReadBug();
applet.init();
this.getContentPane().add(applet);
}
}
new DriverFrame().show();
}
}
Here's test.html:
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="GENERATOR" content="Mozilla/4.51 [en] (Win95; U) [Netscape]">
<title>HTML read test
</title>
</head>
<body>
The HTML tag for the following image is <img SRC="javalogo52x88.gif"
height=88 width=52>
<br><img SRC="javalogo52x88.gif" height=88 width=52>
</body>
</html>
(Review ID: 97509)
======================================================================
|
|
Work Around
|
Don't create a URL from the path on the file system, instead do new File(path).toURL(); so that the correct path separator is used.
xxxxx@xxxxx 2000-02-02
|
|
Evaluation
|
Something seems to have changed in how URL(URL, String) is implemented. The user is taking a path on the Windows file system, creating a URL with that path, and then creating another URL with the previous URL as the base.
Here is a code snippet:
base = new URL("file", null, "c:\prog\doc\test.html");
logoURL = new URL(base, "logo.gif");
On 1.2.x this yields:
base file:c:\prog\doc\test.html
logoURL file:c:/prog/doc/logo.gif
on 1.3 this yields:
base file:c:\prog\doc\test.html
logoURL file:logo.gif
I am reassinging to java.net to make the call on the expected behavior of the constructor URL(URL, String) when base URL has \ as the path separator. As far as I know, \ isn't a valid URL path separator and this isn't a bug. But, I'll let the java.net folks make the call.
xxxxx@xxxxx 2000-02-02
Right. Using a '\' as a file seperator in a URL is illegal. The
'\' character is an "unwise" character according to rfc2396 and
should never be used in a URL (if you really want a '\' character
in a URL you should encode it as "%5C". Instead, you have
to use '/'. We sort of try to be backwards compatible in the "file:"
URL handler and flip backslashes to forward slashes on win32 before
performing an actual URL resource fetch but we didn't play this game
when performing relative URL folding against a base URL. Perhaps we
should have been more lenient and, if we get enough negative feedback,
perhaps we will try to address this in a dot dot release after 1.3.0.
However, it is a true statement that URLs with backslashes are not
legal.
Instead of taking a file path typed by a user into a popup panel and
directly passing it to the URL class as in the bug description you
should instead use that to create a File object and then call toURL().
This will automatically flip the backslashes for you and should also
automate other tasks such as encoding other illegal characters for
example turning the space character ' ' into "%20". It is a bug (4273532) that
toURL() doesn't actually do this but it will soon and when it does you
will inherit the fix. So,
OLD:
java.net.URL url = new java.net.URL("file",null,fileName);
NEW:
java.net.URL url = new java.io.File(fileName).toURL();
xxxxx@xxxxx 2000-02-02
|
|
Comments
|
PLEASE NOTE: JDK6 is formerly known as Project Mustang
|
|
|
|
