SRC parameter not working in Mozilla when path is included

W

wylbur37

(This is a re-post of something that apparently did not post correctly
the first time, so if there's more than one copy, please ignore the
duplicate).

I normally use Mozilla 1.4 on Windows XP Pro.
As I was developing some test webpages, I discovered that the SRC
parameter doesn't seem to work when a path is used with the filename.

In one example, when I want to run a JavaScript from an external file
(i.e., not inline), I would do the following ...

<SCRIPT LANGUAGE="JavaScript" SRC="program.js"> </SCRIPT>

If "program.js" were in a different subdirectory than the .htm file
referring to it, the filename would have to be prefixed by the
pathname as follows ...

<SCRIPT LANGUAGE="JavaScript" SRC="/mydir/program.js"> </SCRIPT>

But when I ran the above from within an .htm file loaded locally into
Mozilla, it did not work. (The result was as if the above code weren't
there). However, when I ran the identical code on Internet Explorer
(v.6), it worked.


In another, even simpler example, the code to put an image on a
webpage is ...

<img src="picture.jpg">

Again, if "picture.jpg were in a different subdirectory than the .htm
file referring to it, the filename would have to be prefixed by the
pathname as follows ...

<img src="/mydir/picture.jpg">

When I ran the above from within an .htm file loaded locally into
Mozilla, it did not work. (The result was as if the above code weren't
there). However, when I ran the identical code on Internet Explorer
(v.6), it worked.


By the way, I tried using backslashes instead of forward slashes. In
both cases, it still worked on Internet Explorer but not on Mozilla.


The SRC parameter seems like a fairly frequently used parameter for
the developers of Mozilla to overlook it. Is this really a bug in
Mozilla or is it just some option/switch in Mozilla that I didn't set
properly?


__________________________________
Do you Yahoo!?
Find out what made the Top Yahoo! Searches of 2003
http://search.yahoo.com/top2003
 
L

Lee

wylbur37 said:
The SRC parameter seems like a fairly frequently used parameter for
the developers of Mozilla to overlook it. Is this really a bug in
Mozilla or is it just some option/switch in Mozilla that I didn't set
properly?

Neither.

An URL beginning with a "/" is invalid. Since it isn't relative to
the URL of the current page, you must specify the protocol. IE lets
you get away with it, assuming that you mean the "file:" protocol.

There are many reasons why it's bad for a browser to make that sort
of assumption, but they are balanced by the fact that accepting bad
code will trick some people into thinking that the other browsers
are buggy, and so they will be less likely to support them, giving
the more lenient browsers a market advantage.

The correct tag would be:

<script type="text/javascript" src="file:///C:/mydir/program.js">

You should see that format in the Location bar when you open any
local HTML file.
 
L

Lasse Reichstein Nielsen

Lee said:
An URL beginning with a "/" is invalid. Since it isn't relative to
the URL of the current page, you must specify the protocol. IE lets
you get away with it, assuming that you mean the "file:" protocol.

It is not invalid in general. As an URI fragment, it defines an
absolute path, relative to the current protocol and server. It is
correct for IE to assume the "file" protocol and "localhost"
server. Where it gets dicey is what happens on local files.

If the URL to the local file is
file://localhost/c:/somedire/myhtml/foo.html
then using the URI fragment in that context "/mydir/program.js" should
give
file://localhost/mydir/program.js
That is most likely not what is wanted. For one thing, it doesn't include
a drive letter. I guess it is what Mozilla does (ok, let me check ... yes,
it gives
file:///mydir/program.js
which is equivalent - omitting the server name in a file protocol means
the server is localhost).

If you compare it to IE, the same test gives:
file:///D:/mydir/program.js
(my test file was on the D: drive). That is incorrect according to
the definition of URIs, but obviously works better on windows based
machines.

Mozilla also runs on, e.g., Unix machines, where there are no drive
letters, so I can see why the want to keep the code general.
There are many reasons why it's bad for a browser to make that sort
of assumption, but they are balanced by the fact that accepting bad
code will trick some people into thinking that the other browsers
are buggy, and so they will be less likely to support them, giving
the more lenient browsers a market advantage.

Hear, hear!
<script type="text/javascript" src="file:///C:/mydir/program.js">

The problem is that you need to change the file before uploading
to a server. The advantage is that it works locally :)

/L
 
M

Michael Winter

An URL beginning with a "/" is invalid. Since it isn't relative to
the URL of the current page, you must specify the protocol. IE lets
you get away with it, assuming that you mean the "file:" protocol.

That statement is incorrect as long as the document has a base URL; either
specified explicitly or derived from the document (it's file: or http:
URL). A URL beginning with a single forward slash would be parsed like so:

base: http://www.example.com/html/main.html

abs: /mydir/picture.jpeg -> http://www.example.com/mydir/picture.jpeg

If 'mydir' was a subdirectory in 'html', the relative URL should be:

rel: ./mydir/picture.jpeg ->
http://www.example.com/html/mydir/picture.jpeg

OR:

rel: mydir/picture.jpeg

You were correct though that a URL beginning with a forward slash is not
relative.

Using the file: scheme, the results should be similar: a single slash
would begin from the root directory of the current drive. However, RFC
1808 doesn't give examples for the file: scheme (probably due to numerous
and dissimilar filesystem formats).

<snip>

Mike


RFC 1808: http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc1808.html

There is a list of examples towards the end of the document
(Section 5.1 - Normal Examples) that include a single, initial
forward slash.
 
M

Michael Winter

The problem is that you need to change the file before uploading
to a server. The advantage is that it works locally :)

However, the simple thing is to mirror the directory structure on the
server on the development machine(s) as well (it's what I do). If you only
use relative URLs, with '../' used as necessary, you need to change
nothing, and it works locally, too. Of course, you need to plan your
directory structures carefully first, but shouldn't you always do that?

Mike
 
L

Lasse Reichstein Nielsen

Michael Winter said:
However, the simple thing is to mirror the directory structure on the
server on the development machine(s) as well (it's what I do). If you
only use relative URLs, with '../' used as necessary, you need to
change nothing, and it works locally, too.

Yes, as long as the paths are in relation to the HTML file, it is
simple. However, if your javascript files contain paths as well, it
becomes difficult. E.g., this code in an external file:

function makeMyImg() {
var img = new Image();
img.src = "../images/myImage.png";
return img;
}

The problem is that when that code is called from an HTML page, the path
is taken relative to the HTML file, not the Javascript file. If you have
HTML files in different levels of directories, no relative path will
work for all of them. That makes absolute paths necessary for Javascript
files that are shared between different pages.
Of course, you need to plan your directory structures carefully
first, but shouldn't you always do that?

Absolutely. And always sooner than you expect :)

/L
 
K

kaeli

[email protected] enlightened us said:
The problem is that when that code is called from an HTML page, the path
is taken relative to the HTML file, not the Javascript file. If you have
HTML files in different levels of directories, no relative path will
work for all of them. That makes absolute paths necessary for Javascript
files that are shared between different pages.

Actually, I always use relative paths because of portability, and I had
to write a workaround to just this problem.
What I did was basically check where I was and write the source element
dynamically.

It was a server-side solution (coldfusion), but I bet it could be done
client-side as well, if needed.

--
 
G

Grant Wagner

Lasse said:
The problem is that you need to change the file before uploading
to a server. The advantage is that it works locally :)

The solution is to install and run an httpd on the development PC, then you are
accessing the site using the same protocol and file paths as you will on the
real server.

--
| Grant Wagner <[email protected]>

* Client-side Javascript and Netscape 4 DOM Reference available at:
*
http://devedge.netscape.com/library/manuals/2000/javascript/1.3/reference/frames.html

* Internet Explorer DOM Reference available at:
*
http://msdn.microsoft.com/workshop/author/dhtml/reference/dhtml_reference_entry.asp

* Netscape 6/7 DOM Reference available at:
* http://www.mozilla.org/docs/dom/domref/
* Tips for upgrading JavaScript for Netscape 7 / Mozilla
* http://www.mozilla.org/docs/web-developer/upgrade_2.html
 
D

Dr John Stockton

JRS: In article <[email protected]>, seen in
news:comp.lang.javascript said:
function makeMyImg() {
var img = new Image();
img.src = "../images/myImage.png";
return img;
}

The problem is that when that code is called from an HTML page, the path
is taken relative to the HTML file, not the Javascript file. If you have
HTML files in different levels of directories, no relative path will
work for all of them. That makes absolute paths necessary for Javascript
files that are shared between different pages.


When a page is being written, one should know its position on the site.

So surely the function should be along the lines of

function makeMyImg(PartPath) {
var img = new Image();
img.src = PartPath + "images/myImage.png";
return img;
}

or even have the full name of the image passed as a parameter?
 
R

Richard Cornford

... But on the local machine mydir is searched in the
root dir - wherever this may be on Windows machines
(not C: at least on Win98).
<snip>

If you look at a file protocol URL on a Windows machine, such as -
file:///C:/mydir/program.js
- you may notice that the "file:" part is separated from the rest of
the URL by three slashes instead of the two that would usually be in
that location. The last of those three slashes represents the root
directory and as that is above the level of the drive letter it clearly
cannot represent any real location in the file system of a windows
machine. IE browsers seem to confuse the issue by applying the same path
rules that the OS uses when resolving file names.

Richard.
 
L

Lasse Reichstein Nielsen

Richard Cornford said:
If you look at a file protocol URL on a Windows machine, such as -
file:///C:/mydir/program.js
- you may notice that the "file:" part is separated from the rest of
the URL by three slashes instead of the two that would usually be in
that location. The last of those three slashes represents the root
directory

No. It separates the server from the path. In file URL's the server
can be omitted if it is "localhost", but the above is equivalent to
the URI
file://localhost/C:/mydir/program.js
The usual rules apply, so this can be separated using the grammar
productions (RFC 2396 section 3):

absoluteURI :: scheme ":" hier_part
hier_part :: net_path
net_path :: "//" authority [abs_path]
abs_path :: "/" path_segments

Here, scheme is "file", authority is the "localhost" server and
path_segments is "C:/mydir/program.js".

There is no initial slash in the path segments, but when the
scheme+server is specified, the path is necessarily absolute.

/L
 
T

Thomas 'PointedEars' Lahn

Lasse said:
The problem is that when that code is called from an HTML page, the path
is taken relative to the HTML file, not the Javascript file. If you have
HTML files in different levels of directories, no relative path will
work for all of them. That makes absolute paths necessary for Javascript
files that are shared between different pages.

It does not. In the linked script file you can retrieve the URL of
the linking document, as for example (from my box of olde things ;-)):

function CalcPaths() { /* Calculates relative image file paths to
absolute ones */
var PathEnd = document.URL.lastIndexOf('\\'); // Folder path
if (PathEnd == -1)
PathEnd = document.URL.lastIndexOf('/'); // URL
if (PathEnd == -1) { // Extends filename to full path
var prevImgCollapsed = imgCollapsed;
imgCollapsed = document.URL.slice(0, PathEnd);
imgCollapsed += "/";
imgCollapsed += prevImgCollapsed;
var prevImgExpanded = imgExpanded;
imgExpanded = document.URL.slice(0, PathEnd);
imgExpanded += "/";
imgExpanded += prevImgExpanded;
}
}


PointedEars
 
M

Michael C.

(This is a re-post of something that apparently did not post correctly
the first time, so if there's more than one copy, please ignore the
duplicate).

I normally use Mozilla 1.4 on Windows XP Pro.
As I was developing some test webpages, I discovered that the SRC
parameter doesn't seem to work when a path is used with the filename.

In one example, when I want to run a JavaScript from an external file
(i.e., not inline), I would do the following ...

<SCRIPT LANGUAGE="JavaScript" SRC="program.js"> </SCRIPT>

If "program.js" were in a different subdirectory than the .htm file
referring to it, the filename would have to be prefixed by the
pathname as follows ...

<SCRIPT LANGUAGE="JavaScript" SRC="/mydir/program.js"> </SCRIPT>

Try

<SCRIPT LANGUAGE="JavaScript" SRC="file:///mydir/program.js">
</SCRIPT>

or

<SCRIPT LANGUAGE="JavaScript"
SRC="http://my.server.org/mydir/program.js">
</SCRIPT>

AFAIK, you don't assume a server. Just because it works in IE, doesn't
make it correct. And don't use backslashes, IE might not balk at them,
but if you ever want to view the files in anything but IE, you'll be
disappointed.

HTH,

Michael C.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,900
Latest member
Nell636132

Latest Threads

Top